Andy Young
2014-10-20 08:09:16 UTC
Hello.
I am using cdrdao for a large internal ripping project. All CDRs are from our internal archives and therefore not cross verifiable of any sort of CDDB.
Most of the discs have track pre-gaps, and I am having slightly undefined behaviour and would appreciate an explanation if anyone can help.
If I run a track pre-gap detection pass, I get TOC contents that I can recreate across different brands of DVD recorder.
Command line for track pre-gap detection pass:
cdrdao read-toc -v 3 --driver generic-mmc --device /dev/sr1 --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_full_toc.toc
If I try to use the TOC that's created as part of the cd read process I get slightly different different toc contents depending on the drive used.
cdrdao read-cd -v 3 --driver generic-mmc --device /dev/sr1 --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_readcd.toc
With a given sample disc, I get the following results for the disc "start" in the TOC:
Plextor drive: Track 0: 00:00:00, Track 1: 00:00:07, Track 2: 00:00:12
Dell drive: Track 0: 00:00:00 , Track 1: 00:00:07, Track 2: 00:00:23
Read-TOC (Plextor and Dell): Track 0: 00:00:00 , Track 1: 00:01:73, Track 2: 00:01:73
The Read-TOC result of 00:01:73 is what appears to be correct.
My main question is, whether the TOC information from the read-cd command is completely arbitrary or based on some parameter I don't understand fully.
( In this disc instance the Dell 00:00:23 frame Vs Plextor 00:00:12 frame track pre-gap difference in the resulting TOC file causes the cut to happen slightly in the wrong place and I get about 1/7th of a second of tone from the start of track #3 bleeding into the end of silence at the end of track #2. )
One other think of note is that if I try to fast read the TOC to ignore track pre gaps entirely, the offsets are wrong as the CD image file appears to contain the track pre-gaps within, so the cuts are in the wrong place.
cdrdao read-toc -v 3 --driver generic-mmc --device /dev/sr1 --fast-toc --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_fast_toc.toc
The ultimate aim is to rip with cdrdao, then use toc2cue, then bchunk to split the CD images into WAV files.
Thanks in advance for any enlightenment!
Andy Young
Systems Specialist
Digital Media Services
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
----------------------------
I am using cdrdao for a large internal ripping project. All CDRs are from our internal archives and therefore not cross verifiable of any sort of CDDB.
Most of the discs have track pre-gaps, and I am having slightly undefined behaviour and would appreciate an explanation if anyone can help.
If I run a track pre-gap detection pass, I get TOC contents that I can recreate across different brands of DVD recorder.
Command line for track pre-gap detection pass:
cdrdao read-toc -v 3 --driver generic-mmc --device /dev/sr1 --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_full_toc.toc
If I try to use the TOC that's created as part of the cd read process I get slightly different different toc contents depending on the drive used.
cdrdao read-cd -v 3 --driver generic-mmc --device /dev/sr1 --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_readcd.toc
With a given sample disc, I get the following results for the disc "start" in the TOC:
Plextor drive: Track 0: 00:00:00, Track 1: 00:00:07, Track 2: 00:00:12
Dell drive: Track 0: 00:00:00 , Track 1: 00:00:07, Track 2: 00:00:23
Read-TOC (Plextor and Dell): Track 0: 00:00:00 , Track 1: 00:01:73, Track 2: 00:01:73
The Read-TOC result of 00:01:73 is what appears to be correct.
My main question is, whether the TOC information from the read-cd command is completely arbitrary or based on some parameter I don't understand fully.
( In this disc instance the Dell 00:00:23 frame Vs Plextor 00:00:12 frame track pre-gap difference in the resulting TOC file causes the cut to happen slightly in the wrong place and I get about 1/7th of a second of tone from the start of track #3 bleeding into the end of silence at the end of track #2. )
One other think of note is that if I try to fast read the TOC to ignore track pre gaps entirely, the offsets are wrong as the CD image file appears to contain the track pre-gaps within, so the cuts are in the wrong place.
cdrdao read-toc -v 3 --driver generic-mmc --device /dev/sr1 --fast-toc --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_fast_toc.toc
The ultimate aim is to rip with cdrdao, then use toc2cue, then bchunk to split the CD images into WAV files.
Thanks in advance for any enlightenment!
Andy Young
Systems Specialist
Digital Media Services
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
----------------------------