search

superg / redumper

Low level CD dumper utility
GNU General Public License v3.0
200 stars 18 forks source link

Feature suggestion: cdrdao's bin+toc as output format ? #70

Open vpelletier opened 1 year ago

vpelletier commented 1 year ago

While bin+cue is a more popular image format, cdrdao's bin+toc (scroll to "Toc File" section for format description) can contain subchannels (either deinterleaved or interleaved, but in both case they seem to be aggregated at the end of the corresponding sector) in standard, which I believe is not available with bin+cue.

I would also like to mention mame's chd format, which makes bin+toc and bin+cue easier to keep track of (all-in-one file) and smaller (lossless compression). This said, I do not know if it would be reasonable to have a built-in implementation of the CHD creation logic, so I guess this could be a suggestion in the documentation as a further processing step.

superg commented 1 year ago

Primary raw redumper output is .scram and .subcode. That's the extended cd space raw data that includes lead-in and lead-out. .bin/.cue is just an extract from that data but if you want to preserve disc the best way, keep all the primary generated redumper files.

Technically, I can generate everything else from .scram and .subcode if needed. But I am not sure if .bin/.toc brings a lot of value. text .toc isn't widely used and on my experience I saw it only in cdrdao.

Now, another thing to mention is that if you merge subchannel and bin together in one file, each dump will be different and you will not be able to match files. Subchannel data doesn't have any error correction and you always get errors there. It mostly can be regenerated/guessed but that would be data manipulation and the aim here is to get the CD exactly how it was mastered.

tjanas commented 1 year ago

I think it would be more useful to have ccd/img/sub with the .sub being refine-able (and ccd/img/sub is supported on some real hardware ODEs, useful for when subs are needed, like CD+G).