From 571982345a32d7a2e31d664b59950792be5f21ea Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Tue, 12 May 2020 04:36:23 -0400 Subject: detect ECM files and abort --- cuerecover.1 | 75 +++++++++++++++++++++++++++++++++++++++---------------- cuerecover.c | 5 ++++ cuerecover.html | 61 +++++++++++++++++++++++++++++++-------------- cuerecover.rst | 76 ++++++++++++++++++++++++++++++++++++++------------------ miragextract.rst | 6 ++--- 5 files changed, 156 insertions(+), 67 deletions(-) diff --git a/cuerecover.1 b/cuerecover.1 index 7395e91..354e2e5 100644 --- a/cuerecover.1 +++ b/cuerecover.1 @@ -55,17 +55,11 @@ represent one track of the same CD image. For data tracks, the recovered track should be correct, provided the bin file wasn\(aqt truncated or otherwise corrupted. .sp -For audio tracks, silence detection is used to find the start of the track -(the INDEX 01 in the .cue file). -.sp For audio tracks in a single .bin file, silence detection is used to find the split points between tracks. This means that in cases where one track segues into another, the two tracks will be combined in the resulting cue sheet. Also, if there are long periods of silence within a single track, this track will be split into two or more tracks. -.sp -[*] \fIOnly\fP the .cue file is written to stdout. Status and progress -messages are printed to standard error. .SH OPTIONS .INDENT 0.0 .TP @@ -75,7 +69,9 @@ Print short usage string. .BI \-o \ Write cue file to \fIfile\fP rather than standard output. If \fIfile\fP already exists, cuerecover will refuse to overwrite it, -which makes this safer than redirecting stdout. +which makes this safer than redirecting stdout. It\(aqs customary +for cue files to have the same filename as their bin file(s), +with the .bin replaced by .cue, but it\(aqs not actually required. .TP .BI \-s \ Minimum amount of silence for detecting the split point between @@ -105,10 +101,19 @@ cuerecover is doing. Probably only of interest to the author. Always include a space between an option and its argument (e.g. \fB\-s 1\fP, not \fB\-s1\fP). .SH NOTES .sp -When reading multiple tracks from the same file, cuerecover makes some -assumptions. These are usually valid, but should be mentioned here: +cuerecover works a lot better when it\(aqs reading a split image (one file +per track). +.sp +When reading a monolithic image (multiple tracks the same file), +cuerecover has to make some assumptions. These are usually valid, but +should be mentioned here: .INDENT 0.0 .IP \(bu 2 +The disc image is a single session. Actually multisession discs might +work too, but I have no examples to test with. If you\(aqre dealing with +an image of a commercial release (a game, probably), it\(aqll be single +session. +.IP \(bu 2 The tracks are all MODE1 (data), MODE2 (also data, usually video CDs) or CD\-DA (regular CD audio). Extended format CDs like XA or CD+I are not supported, though you might still get listenable audio tracks from them. @@ -120,19 +125,31 @@ data tracks that aren\(aqt the first track on the disc. .IP \(bu 2 If there\(aqs a data track, it\(aqs a raw image (2352 bytes per sector, includes the sync pulse, address, CRC, ECC, etc). If the data track was stored as -\(aqcooked\(aq data (2048 bytes/sector, MODE1/2048 in the original .cue file), -it\(aqll be treated as an audio track, and you\(aqll get a warning that it -looks like \(aqcooked\(aq data. You can check for this by trying to -mount the .bin file as an ISO or HFS image: if it mounts, the first -track is \(aqcooked\(aq. It\(aqll also be obvious if you use the .cue sheet to -extract the image into files: ISO images don\(aqt sound musical at all! +\(aqcooked\(aq data (2048 bytes/sector, MODE1/2048 in the original .cue +file), it\(aqll be treated as an audio track (or more likely 20 or 30 +audio tracks), and you\(aqll get a warning that it looks like \(aqcooked\(aq +data. You can check for this by trying to mount the .bin file as an +ISO or HFS image: if it mounts, the first track is \(aqcooked\(aq. .IP \(bu 2 -cuerecover will generate \fIa\fP cue file, which will be valid... but it may -not match the original (missing) one exactly. This is because cuerecover -has to look for silent sections of the image and use those as split points -for the tracks. If there\(aqs a 3\-second silent section between tracks 2 and -3, is that 1 second of silence at the end of track 2 + 2 seconds of silence -at the start of track 3, or vice versa, or 1.5 seconds each, or...? +If a data track gets mis\-identified as a file, it\(aqll be obvious if +you use the .cue sheet to extract the image into files: you\(aqll +probably get way too many tracks, since most filesystem images have +long stretches of "silence" (long runs of zeroes). If you try to listen +to these, you\(aqll notice that ISO images don\(aqt sound musical at all! +The last few tracks will be the largest, and these will be valid audio, +if there were any audio tracks. +.IP \(bu 2 +Audio tracks are separated by at least 2 seconds of silence (or whatever +you set \-s to). If not, there\(aqs no way to detect where one track ends +and the next begins, so they\(aqll get merged together. +.IP \(bu 2 +In the best case scenario, cuerecover will generate \fIa\fP cue file, which +will be valid... but it may not match the original (missing) one +exactly. This is because cuerecover has to look for silent sections +of the image and use those as split points for the tracks. If there\(aqs +a 3\-second silent section between tracks 2 and 3, is that 1 second of +silence at the end of track 2 and 2 seconds of silence at the start of +track 3, or vice versa, or 1.5 seconds each, or...? .UNINDENT .\" other sections we might want, uncomment as needed. . @@ -162,5 +179,21 @@ released under the WTFPL: Do WTF you want with this. .SH SEE ALSO .sp miragextract(1) +.sp +The manual for GNU ccd2cue(1) has useful information on the .cue +file format: +.INDENT 0.0 +.INDENT 3.5 +\fI\%https://www.gnu.org/software/ccd2cue/manual/html_node/CUE\-sheet\-format.html\fP +.UNINDENT +.UNINDENT +.sp +More information on the CD\-ROM data formats: +.INDENT 0.0 +.INDENT 3.5 +\fI\%https://wiki.osdev.org/User:Combuster/CDRom_BS\fP +\fI\%https://en.wikipedia.org/wiki/CD\-ROM\fP +.UNINDENT +.UNINDENT .\" Generated by docutils manpage writer. . diff --git a/cuerecover.c b/cuerecover.c index 40698e3..89a7e7a 100644 --- a/cuerecover.c +++ b/cuerecover.c @@ -54,6 +54,11 @@ int looks_like_filesystem(const char *filename, FILE *f) { return 0; } + if(buf[0] == 'E' && buf[1] == 'C' && buf[2] == 'M') { + fprintf(stderr, "%s: file %s is ECM, use 'ecm2bin' to convert to raw bin\n", self, filename); + exit(1); + } + if(buf[0] == 'E' && buf[1] == 'R' && buf[3] == 0 && (buf[2] == 0x02 || buf[2] == 0x08)) { have_apple_magic++; diff --git a/cuerecover.html b/cuerecover.html index 7de40e0..7e9f469 100644 --- a/cuerecover.html +++ b/cuerecover.html @@ -396,15 +396,11 @@ might only be one). If multiple .bin files are given, each one is assumed to represent one track of the same CD image.

For data tracks, the recovered track should be correct, provided the bin file wasn't truncated or otherwise corrupted.

-

For audio tracks, silence detection is used to find the start of the track -(the INDEX 01 in the .cue file).

For audio tracks in a single .bin file, silence detection is used to find the split points between tracks. This means that in cases where one track segues into another, the two tracks will be combined in the resulting cue sheet. Also, if there are long periods of silence within a single track, this track will be split into two or more tracks.

-

[*] Only the .cue file is written to stdout. Status and progress -messages are printed to standard error.

OPTIONS

@@ -419,7 +415,9 @@ messages are printed to standard error.

-o <file> Write cue file to file rather than standard output. If file already exists, cuerecover will refuse to overwrite it, -which makes this safer than redirecting stdout. +which makes this safer than redirecting stdout. It's customary +for cue files to have the same filename as their bin file(s), +with the .bin replaced by .cue, but it's not actually required. -s <sec> Minimum amount of silence for detecting the split point between @@ -450,9 +448,16 @@ cuerecover is doing. Probably only of interest to the author.

NOTES

-

When reading multiple tracks from the same file, cuerecover makes some -assumptions. These are usually valid, but should be mentioned here:

+

cuerecover works a lot better when it's reading a split image (one file +per track).

+

When reading a monolithic image (multiple tracks the same file), +cuerecover has to make some assumptions. These are usually valid, but +should be mentioned here:

    +
  • The disc image is a single session. Actually multisession discs might +work too, but I have no examples to test with. If you're dealing with +an image of a commercial release (a game, probably), it'll be single +session.
  • The tracks are all MODE1 (data), MODE2 (also data, usually video CDs) or CD-DA (regular CD audio). Extended format CDs like XA or CD+I are not supported, though you might still get listenable audio tracks from them.
    • @@ -462,18 +467,28 @@ from the CD-ROM era (and even modern ones) don't provide access to data tracks that aren't the first track on the disc.
  • If there's a data track, it's a raw image (2352 bytes per sector, includes the sync pulse, address, CRC, ECC, etc). If the data track was stored as -'cooked' data (2048 bytes/sector, MODE1/2048 in the original .cue file), -it'll be treated as an audio track, and you'll get a warning that it -looks like 'cooked' data. You can check for this by trying to -mount the .bin file as an ISO or HFS image: if it mounts, the first -track is 'cooked'. It'll also be obvious if you use the .cue sheet to -extract the image into files: ISO images don't sound musical at all!
    • -
  • cuerecover will generate a cue file, which will be valid... but it may -not match the original (missing) one exactly. This is because cuerecover -has to look for silent sections of the image and use those as split points -for the tracks. If there's a 3-second silent section between tracks 2 and -3, is that 1 second of silence at the end of track 2 + 2 seconds of silence -at the start of track 3, or vice versa, or 1.5 seconds each, or...?
    • +'cooked' data (2048 bytes/sector, MODE1/2048 in the original .cue +file), it'll be treated as an audio track (or more likely 20 or 30 +audio tracks), and you'll get a warning that it looks like 'cooked' +data. You can check for this by trying to mount the .bin file as an +ISO or HFS image: if it mounts, the first track is 'cooked'. +
  • If a data track gets mis-identified as a file, it'll be obvious if +you use the .cue sheet to extract the image into files: you'll +probably get way too many tracks, since most filesystem images have +long stretches of "silence" (long runs of zeroes). If you try to listen +to these, you'll notice that ISO images don't sound musical at all! +The last few tracks will be the largest, and these will be valid audio, +if there were any audio tracks.
    • +
  • Audio tracks are separated by at least 2 seconds of silence (or whatever +you set -s to). If not, there's no way to detect where one track ends +and the next begins, so they'll get merged together.
    • +
  • In the best case scenario, cuerecover will generate a cue file, which +will be valid... but it may not match the original (missing) one +exactly. This is because cuerecover has to look for silent sections +of the image and use those as split points for the tracks. If there's +a 3-second silent section between tracks 2 and 3, is that 1 second of +silence at the end of track 2 and 2 seconds of silence at the start of +track 3, or vice versa, or 1.5 seconds each, or...?
@@ -497,6 +512,14 @@ released under the WTFPL: Do WTF you want with this.

SEE ALSO

miragextract(1)

+

The manual for GNU ccd2cue(1) has useful information on the .cue +file format:

+
+https://www.gnu.org/software/ccd2cue/manual/html_node/CUE-sheet-format.html
+

More information on the CD-ROM data formats:

+
+https://wiki.osdev.org/User:Combuster/CDRom_BS +https://en.wikipedia.org/wiki/CD-ROM
diff --git a/cuerecover.rst b/cuerecover.rst index 813ed4c..1918c99 100644 --- a/cuerecover.rst +++ b/cuerecover.rst @@ -39,18 +39,12 @@ represent one track of the same CD image. For data tracks, the recovered track should be correct, provided the bin file wasn't truncated or otherwise corrupted. -For audio tracks, silence detection is used to find the start of the track -(the INDEX 01 in the .cue file). - For audio tracks in a single .bin file, silence detection is used to find the split points between tracks. This means that in cases where one track segues into another, the two tracks will be combined in the resulting cue sheet. Also, if there are long periods of silence within a single track, this track will be split into two or more tracks. -[*] *Only* the .cue file is written to stdout. Status and progress -messages are printed to standard error. - OPTIONS ======= @@ -59,7 +53,9 @@ OPTIONS -o Write cue file to *file* rather than standard output. If *file* already exists, cuerecover will refuse to overwrite it, - which makes this safer than redirecting stdout. + which makes this safer than redirecting stdout. It's customary + for cue files to have the same filename as their bin file(s), + with the .bin replaced by .cue, but it's not actually required. -s Minimum amount of silence for detecting the split point between two audio tracks. Argument is in seconds, and decimals @@ -87,8 +83,17 @@ Always include a space between an option and its argument (e.g. **-s 1**, not ** NOTES ===== -When reading multiple tracks from the same file, cuerecover makes some -assumptions. These are usually valid, but should be mentioned here: +cuerecover works a lot better when it's reading a split image (one file +per track). + +When reading a monolithic image (multiple tracks the same file), +cuerecover has to make some assumptions. These are usually valid, but +should be mentioned here: + +- The disc image is a single session. Actually multisession discs might + work too, but I have no examples to test with. If you're dealing with + an image of a commercial release (a game, probably), it'll be single + session. - The tracks are all MODE1 (data), MODE2 (also data, usually video CDs) or CD-DA (regular CD audio). Extended format CDs like XA or CD+I are not @@ -101,19 +106,31 @@ assumptions. These are usually valid, but should be mentioned here: - If there's a data track, it's a raw image (2352 bytes per sector, includes the sync pulse, address, CRC, ECC, etc). If the data track was stored as - 'cooked' data (2048 bytes/sector, MODE1/2048 in the original .cue file), - it'll be treated as an audio track, and you'll get a warning that it - looks like 'cooked' data. You can check for this by trying to - mount the .bin file as an ISO or HFS image: if it mounts, the first - track is 'cooked'. It'll also be obvious if you use the .cue sheet to - extract the image into files: ISO images don't sound musical at all! - -- cuerecover will generate *a* cue file, which will be valid... but it may - not match the original (missing) one exactly. This is because cuerecover - has to look for silent sections of the image and use those as split points - for the tracks. If there's a 3-second silent section between tracks 2 and - 3, is that 1 second of silence at the end of track 2 + 2 seconds of silence - at the start of track 3, or vice versa, or 1.5 seconds each, or...? + 'cooked' data (2048 bytes/sector, MODE1/2048 in the original .cue + file), it'll be treated as an audio track (or more likely 20 or 30 + audio tracks), and you'll get a warning that it looks like 'cooked' + data. You can check for this by trying to mount the .bin file as an + ISO or HFS image: if it mounts, the first track is 'cooked'. + +- If a data track gets mis-identified as a file, it'll be obvious if + you use the .cue sheet to extract the image into files: you'll + probably get way too many tracks, since most filesystem images have + long stretches of "silence" (long runs of zeroes). If you try to listen + to these, you'll notice that ISO images don't sound musical at all! + The last few tracks will be the largest, and these will be valid audio, + if there were any audio tracks. + +- Audio tracks are separated by at least 2 seconds of silence (or whatever + you set -s to). If not, there's no way to detect where one track ends + and the next begins, so they'll get merged together. + +- In the best case scenario, cuerecover will generate *a* cue file, which + will be valid... but it may not match the original (missing) one + exactly. This is because cuerecover has to look for silent sections + of the image and use those as split points for the tracks. If there's + a 3-second silent section between tracks 2 and 3, is that 1 second of + silence at the end of track 2 and 2 seconds of silence at the start of + track 3, or vice versa, or 1.5 seconds each, or...? .. other sections we might want, uncomment as needed. @@ -134,8 +151,8 @@ As usual, 0 for success, non-zero for failure. .. EXAMPLES .. ======== -AUTHORS -======= +AUTHOR +====== cuerecover was written by B. Watson and released under the WTFPL: Do WTF you want with this. @@ -144,3 +161,14 @@ SEE ALSO ======== miragextract(1) + +The manual for GNU ccd2cue(1) has useful information on the .cue +file format: + + https://www.gnu.org/software/ccd2cue/manual/html_node/CUE-sheet-format.html + +More information on the CD-ROM data formats: + + https://wiki.osdev.org/User:Combuster/CDRom_BS + https://en.wikipedia.org/wiki/CD-ROM + diff --git a/miragextract.rst b/miragextract.rst index 2452f0f..6248a15 100644 --- a/miragextract.rst +++ b/miragextract.rst @@ -136,8 +136,8 @@ errors. miragextract exits as soon as it encounters an error of any kind. .. EXAMPLES .. ======== -AUTHORS -======= +AUTHOR +====== miragextract was written by B. Watson and released under the WTFPL: Do WTF you want with this. @@ -145,4 +145,4 @@ released under the WTFPL: Do WTF you want with this. SEE ALSO ======== -TODO: fill in +cuerecover(1), cdemu(1), bchunk(1) -- cgit v1.2.3