>PS1/Saturn/any-other-optical-media-based-console has ISOs, not ROMs
I hate how humans parrot senseless shit like this.
You don't have CD-ISOs?
CD-ROMs are for plebians
>>3351572
>anime reaction pic
>I hate how humans
10/10
>>3351572
>cart based systems use roms instead of digicarts
>>3351576
You have bad taste.
>>3351572
A ROM tends to be a single file, an ISO is basically a zipped version of a multitude of files.
>>3351604
A "rom" is a dump of the read-only data of a certain medium. A dump of a cartridge could have multiple files, just like a dump of a complex Arcade board with multiple files in a raw format (typically .bin).
An "iso" is an improper term for dumps originating from an optical medium. The ISO format itself is bad for anything other than CD-ROMs in the ISO 9660, which is why the format is never used in serious preservation projects, such as Redump. BIN+CUE, MDF+MDS and CCD+IMG are superior and are used instead, especially BIN+CUE.
Some BIN+CUE releases also have several files, as is the case with Redump dumps of games that use CD Audio tracks. Each track is individually dumped in a raw .bin.
"isos" are no less of a "rom" than "regular" SNES "roms".
>>3351619
I really wish someone would be able to standardize some goddamn single file CD filetype, something as simple as a zip file in uncompressed mode with the bin+cue+wav+sub files inside. And then just rename the extension to cdz or something, like what they do with cbz for comic books. That way the dummies wouldn't fuck with the files and distribute broken releases, which is so unfortunately common.
>>3351642
WAV is out of question, it's a sound format, it has to be a raw format. CCD+IMG+SUB is good, but is proprietary and not as supported. And I think it's not "perfectly" raw, .BIN is better for that, which is why it's used for BIOS dumps, for example. No format, however, support information outside of the data tracks, which is beyond the range of any normal optical drive (like Sega Saturn discs, for example).
BIN+CUE is enough to perfectly dump the game data itself, and is perfect already for playing on modded consoles or emulators.
>>3351657
I'm not going to pretend I know anything about the difference of a RAW WAV file and RAW DATA of the audio tracks in a cd, but isn't that just splitting hairs, we're getting lossless audio either way, and everything already supports wav.
>>3351665
WAV is just an audio format, its metadata functions aren't widely supported and doesn't fully replicate the behavior of a Compact Disc Digital Audio (CD-DA) disc, that is a regular music CD, or a Data CD with CD-DA tracks.
Some CD formats like VCD, SVCD, Photo CD, etc. and also PS1 games use the XA extension modes, like XA Mode 2 Form 1. PS1 specifically use XA Mode 2 Form 2.
It is already possible to perfectly copy those formats in BIN+CUE or the other ones I mentioned. A PS1 game won't even WORK if you try to burn it as a regular PC ISO 9660 CD-ROM.
Furthermore, CD-DA has nothing to do with WAV. WAV is just a digital format for storing lossless PCM data. CD-DA is digital but it isn't a file. When audio CDs were invented, the concept of a file on a CD didn't even exist. This is why Windows show the tracks of a music CD as shortcuts. CD-DA tracks aren't files. An audio CD doesn't even have a file structure.
>>3351694
Alright Anon thanks. Sorry for making you type all that out.
>>3351701
Don't be, anon loves making long drawn out posts about how educated he is, he's practically begging for an AMA. Not that there's any problem with that.
>>3351576
>he doesn't recognise minnie may.
>criticising anyone
>>3351694
This was helpful, thank you.
>>3351572
I hate it even more when someone refers to for example Amiga disk dumps as "roms". Fucking console kids.
Nothing you download off the internet is a ROM because you can edit and delete it
>>3351572
Saturn has ROMs kid. Try playing games that need a cart without it. You failed hard my young edgelord.
>>3353753
I like the fact that you didn't even confute OP's point.
>kid
Please leave.
>>3351575
>well-crafted irony
>delivered in minutes
>completely ignored
>2016 4chan
>>3353661
Or DOS ROMs when DOS-box doesn't even use disk images.
>>3351576
go watch gunsmith cats it's awesome
>>3353661
Whenever someone calls them that, I tell them to go play Maniac Mansion on their Nintendo Entertainment System.
>>3351572
haha thanks for making this thread
now can we get everybody who participated it into a bag, and then tie it to a rock and throw it into a river?
>>3351572
Minnie May is cute.
CUTE!
>>3351642
>something as simple as a zip file
Zips are old and busted and would be a good example of why standarisation would hold technology back. If all we had were zips we'd be in dire straights. There NEEDS to be constant newer & better ways of doing things or we keep doing things the dumb way forever like a bunch of cavemen.
The only problem with all the different CD images is that so many of them are tied to shit proprietry software and not open standards.
>>3351619
>storing one file in two or more files
trash
>>3355992
It doesn't have to be a zip file, I just want a simple container, pick your poison.
>>3353768
I like the fact that you can't into reading comprehension and pretend not to be samefag and are underage and are sensitive about it.
>>3356007
7-zip? TAR without file permissions?
>>3356014
I figure tar has better support than 7z, so probably that. At least tar is future proof, all these "new" compression formats come and go eventually. I still remember when .ace was the new hot thing, although shortly lived.
>>3356023
TAR isn't a compression format, it means Tape Archive, and is solely made to turn several files into a single one. That's why TAR-files usually end with tar.gz or tar.bz2 or sometimes tar.xz, that's just some compression laid on top.
>>3356026
Yes I know. Even when I proposed the zip file it was in uncompressed / store mode.
Decompressing 700mb files every time you wanted to load a game wouldn't be too efficient.
>>3353891
Thanks Anon didn't know this china toon. Looks neat
>>3351572
>>PS1/Saturn/any-other-optical-media-based-console has ISOs
>ISOs
Enjoy not being able to emulate anything properly, retard.
>>3351572
>I hate how humans parrot senseless shit like this.
Are you a fucking alien or something?
>>3356003
>poor reading comprehension
Uneducated.
>>3356723
Oh look, it's another dipshit who can't read.
>>3356009
Your headcanon aside, OP said that all ISOs are ROMs but not all ROMs are ISOs, which is what idiots are trying to deny.
But in reality, when a ROM leaves its non-writable container it stops being an actual ROM.
>>3356063
>not knowing Sonoda's works at a glance
>>3353820
You can use them though
>>3353891
And Riding Bean. It's pretty much GSC's prototype.
>>3357882Who
>>3351619
>BIN+CUE, MDF+MDS and CCD+IMG are superior and are used instead, especially BIN+CUE.
ohg what. Bin is not superior. It might be standardized but it only includes all logical data. CloneCD and later alcohols MDS are bins with some physical information extrapolated. So mdf/mds is the superior one for cds.
I imagine that modern games use blurays new data schemes to implement copy protection instead of some physical defect technique
>>3351619
>MDF+MDS ... superior and are used instead
Are you kidding? Hardly anything but daemontools, that malware ridden filth, supports mdf+mds. That sure as fuck ain't preservation.
>>3351642
Why are there CUE files in the first place?
The system has to read the track manifest from the CD, right?
So why isn't that just part of the total BIN dump?
>>3358657
No idea, I'm just assuming bin doesn't support it.
Again to me it really is still pretty bizarre why image dumps have to be done in such a contrived multi file way.
Why didn't cd file formats evolved in a way to dump everything in one place, even subchannel data from which I understand is mostly useless, but still why not have everything copied as accurately as possible in a single organized file. What was nero and alcohol 120% devs thinking back then.
>>3358675
Why doesn't someone just come up with such a format right now?
>>3358679
The problem with formats is standardization. You can come up with a format all you want but if you can't push it to other well known software to support it, it isn't worth dick.
You pretty much need to be a widely used Disc-Burning software or Disc Mounter software to even be able to start making an impact in pushing a new format.
But again you can try your luck, who knows if the open source community will embrace it, that's not a bad start.
>>3358657
A bin is literally a raw binary dump and the cue is a discriptor file. If you added the cue into the bin, it'd no longer be a raw binary dump. Most of these dumping groups are in it for preservation so they last thing they would want is a tainted binary.
Don't know why it really matters to the end user if it's 1 file or 2. Could always rar it or something, I'm sure most emulators can deal with compressed files, although it might add some initial load time.
>>3358793
>Don't know why it really matters to the end user if it's 1 file or 2
To me it doesn't, unfortunately for years this just created conditions in which people uploaded bins without the redbook audio, or without the cue file, or with mp3 files instead of lossless audio tracks, or whatever.
People are dumb and things have to be simple. Making it so ripping a cd would just output a single file with everything in there would remove needless complications which are prone to lead to human error.
>>3359260
>or with mp3 files instead of lossless audio tracks
Always thought it was because of pirates operating before broadband was common. Like removing all non essential assets so they could do a dank 0 day release.
>>3359428
It was out of necessity mostly, most upload sites were 200mb max at the time, so if they were too lazy to upload multiple parts they had to get it all in one 200mb zip file.
>>3359445
Always found funny that the ascii art ridden .NFO would contain something like the size specified in "number of disk(ette)s".
>>3358793
How does a CD player know the track information, then?
If the CUE info isn't part of the image, then where is it on the disc?
>>3360414
Without actually knowing anything on how a cd works I'm assuming the start of the disc is the redbook audio and the rest of the data is relegated to the end. In between data types and tracks there must be a special block of code, like a bunch of empty space or something to identify the differences.
Looking forward to being wrong though, I'm just assuming
>>3361768
>Without actually knowing anything...assuming...Looking forward to being wrong
Your wish is granted
>>3361768
The audio data stream in an audio CD is continuous, but has three parts. The main portion, which is further divided into playable audio tracks, is the program area. This section is preceded by a lead-in track and followed by a lead-out track. The lead-in and lead-out tracks encode only silent audio, but all three sections contain subcode data streams.
The lead-in's subcode contains repeated copies of the disc's Table Of Contents (TOC), which provides an index of the start positions of the tracks in the program area and lead-out. The track positions are referenced by absolute timecode, relative to the start of the program area, in MSF format: minutes, seconds, and fractional seconds called frames. Each timecode frame is one seventy-fifth of a second, and corresponds to a block of 98 channel-data frames—ultimately, a block of 588 pairs of left and right audio samples. Timecode contained in the subchannel data allows the reading device to locate the region of the disc that corresponds to the timecode in the TOC. The TOC on discs is analogous to the partition table on hard drives
