cuerecover

generate .cue file for CD image .bin

Manual section:	1
Manual group:	Urchlay
Date:	2020-05-13
Version:	0.2.0

SYNOPSIS

cuerecover [-o output] [-s sec] [-t thresh] bin-file [bin-file ...]

DESCRIPTION

cuerecover attempts to generate a usable cue sheet for CD images which are missing their .cue (or .ccd, .mds, etc) files.

If a single .bin file is given, it's assumed to hold all the tracks (which 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 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.

OPTIONS

`--help`	Print short usage string.
`-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. 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 two audio tracks. Argument is in seconds, and decimals are allowed. The default is 2, which is the standard sized gap between tracks in the Redbook standard and in most CD authoring software. 0 means to disable splitting tracks: all the audio tracks will be combined into one in the .cue sheet. This option is ignored when multiple .bin file arguments are given, since they're already split into tracks.
`-t <thresh>`	Silence threshold, 0 to 100. Default is 0. This is the percentage of non-zero bytes allowed in a sector for it to be considered silent. Sometimes audio tracks have random data in the pregap (before the INDEX 01), which will fool cuerecover into thinking there's no pregap. This option can help with those, but don't set it too high. This option is ignored when multiple .bin file arguments are given, since they're already split into tracks.
`-v`	Verbose mode. Prints (on stderr) some extra messages about what cuerecover is doing. Probably only of interest to the author.

Always include a space between an option and its argument (e.g. -s 1, not -s1).

NOTES

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.
If there's a data track, it will be the only data track, and it will be track 1. This is almost always the case, since most operating systems 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 (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...?

EXIT STATUS

As usual, 0 for success, non-zero for failure.

AUTHOR

cuerecover was written by B. Watson <yalhcru@gmail.com> and released under the WTFPL: Do WTF you want with this.