-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Package: abcde Version: 2.3.99.5-1
I'm trying to use the abcde from testing to rip CDs to single flac files plus cue information, and the resulting compressed file in some cases does not contain the entire contents of the disk. I initially noticed this as I was ripping CDs first to flac files with embedded cue files (using: abcde -1 -M -o flac). When I then tried to rip ogg files from the resulting flac file (using: abcde -d <file.flac>), the cddb query would show different results than the initial cddb query (ripping the flac file with the actual CD in the drive). I suspected a subtle bug in the cue2discid script, and proceeded to start debugging, but the problem is actually with the embedded cue files themselves. Following are cdparanoia dumps of the TOC for two disks that have given me problems: The Police / Synchronicity (A&M CD-3735) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 15205 [03:22.55] 32 [00:00.32] no no 2 2. 16260 [03:36.60] 15237 [03:23.12] no no 2 3. 18168 [04:02.18] 31497 [06:59.72] no no 2 4. 13920 [03:05.45] 49665 [11:02.15] no no 2 5. 9000 [02:00.00] 63585 [14:07.60] no no 2 6. 22885 [05:05.10] 72585 [16:07.60] no no 2 7. 19052 [04:14.02] 95470 [21:12.70] no no 2 8. 22428 [04:59.03] 114522 [25:26.72] no no 2 9. 23530 [05:13.55] 136950 [30:26.00] no no 2 10. 19162 [04:15.37] 160480 [35:39.55] no no 2 11. 20528 [04:33.53] 179642 [39:55.17] no no 2 TOTAL 200138 [44:28.38] (audio only) Pink Floyd / Dark Side of the Moon (Capitol 7-46001-2) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 17835 [03:57.60] 33 [00:00.33] no no 2 2. 16125 [03:35.00] 17868 [03:58.18] no no 2 3. 31860 [07:04.60] 33993 [07:33.18] no no 2 4. 21530 [04:47.05] 65853 [14:38.03] no no 2 5. 28685 [06:22.35] 87383 [19:25.08] no no 2 6. 35270 [07:50.20] 116068 [25:47.43] no no 2 7. 15425 [03:25.50] 151338 [33:37.63] no no 2 8. 17287 [03:50.37] 166763 [37:03.38] no no 2 9. 9093 [02:01.18] 184050 [40:54.00] no no 2 TOTAL 193110 [42:54.60] (audio only) Note that both tracks have *NON-ZERO* frame offsets for the start of track one. This offset gets *LOST* when the TOC is converted into a cue file, and the first <offset> audio frames *ARE NOT RIPPED* from the CD. Obviously, the missing initial track offset causes problems when generating the cddb query from the resulting flac file. The track start hash calculation is typically affected (without the proper offset, some tracks will be +/- 1s from the value calculated directly from the CD) and the missing initial offset will directly affect the track offsets provided with the extended query. I was able to rip the missing initial frames by calling cdparanoia with a track range of 0- instead of 1-n. Fixing the cue table, however, is more problematic. I altered the mkcue code to only subtract the 2S (150 frame) offset from the LBA when exporting the cue file (resulting in track one starting with a non-zero value on these disks), but metaflac refused to import a cue file that didn't start at 00:00:00. At this point, there doesn't appear to be a simple patch that can fix the problem, so it becomes an abcde design issue. Solutions that come to mind include: - - Store the disc TOC in the flac file, instead of the cue file - - Store a cuefile "offset" for the 'normalized' cue file embedded in the flac file - - Modify metaflac to allow non-zero start positions for track 1 - - ??? - -- Charles Steinkuehler [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFErn+denk4xp+mH40RAnH6AKDQO9m7Y0h5ULC5S7DObjqZd66dxwCgz4Ix 6f7o2DQrH9n+SMHIz5t1BII= =64fa -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
