From: Thomas V. S. <th...@ap...> - 2009-05-24 09:53:07
|
Hello everyone. For a program I'm making, I'm using cdrdao to read TOC tables and pregap information. I've noticed that by default read-toc only gives me the first session. By experimentation I found that, if I pass a non-existent session number higher than 1, I get information for all sessions combined. However, it seems that when I do so information is lost about the pregap. For example, on a CD single with a 12 frame pregap (Pixies, Planet of Sound), reading session 1 gives me this chunk for TRACK 1: // Track 1 TRACK AUDIO NO COPY NO PRE_EMPHASIS TWO_CHANNEL_AUDIO SILENCE 00:00:12 FILE "data.wav" 0 02:07:50 START 00:00:12 While reading session 9 gives me this chunk: // Track 1 TRACK AUDIO NO COPY NO PRE_EMPHASIS TWO_CHANNEL_AUDIO FILE "data.wav" 0 02:07:50 In the output while scanning, for session 1 it also clearly finds the pregap, while for all other "sessions" it doesn't. Additionally it shows this warning at the start: WARNING: Found bogus toc data (0 or > 99 tracks). Please report! WARNING: Your drive probably does not support raw toc reading. WARNING: Using TOC data retrieved with generic method (no multi session support). WARNING: Use driver option 0x10000 to suppress this message. That warning makes sense because there isn't actually a TOC for that session. My best guess is that, when asked for a session that doesn't have a TOC, cdrdao just starts scanning at index 1 of track 1 of the TOC that is there. Can someone comment on what the intended behaviour is of specifying a session that does not exist ? Is it intended that it should give information on all sessions combined, in which case missing the pregap is a bug that needs fixing ? Or is it supposed to error out straight away ? If so, is there any other way cdrdao can read a .toc file for all sessions combined, or should I manually find a way to combine them ? Thanks, Thomas -- everywhere I am is just another thing without you in it -- GStreamer - bringing multimedia to your desktop http://gstreamer.freedesktop.org/ |
From: Denis L. <de...@po...> - 2009-05-24 14:07:00
|
Dag Thomas, On 05/24/2009 11:52 AM, Thomas Vander Stichele wrote: > Can someone comment on what the intended behaviour is of specifying a > session that does not exist ? Is it intended that it should give > information on all sessions combined, in which case missing the pregap > is a bug that needs fixing ? Not sure, I'd have to investigate further, my memory on pregap/session stuff is a bit faint. Session default is indeed 1, and by default only that TOC information is displayed. > Or is it supposed to error out straight away ? If so, is there any other > way cdrdao can read a .toc file for all sessions combined, or should I > manually find a way to combine them ? You can use the option --driver generic-mmc:0x10000 The option (OPT_DRV_GET_TOC_GENERIC) disable the session filter after the generic TOC read, i.e should you get the TOCs for all sessions. What does 'cdrdao msinfo -v 4' show ? -denis |
From: Thomas V. S. <th...@ap...> - 2009-05-24 17:56:25
|
On Sun, 2009-05-24 at 16:06 +0200, Denis Leroy wrote: > Dag Thomas, > > On 05/24/2009 11:52 AM, Thomas Vander Stichele wrote: > > Can someone comment on what the intended behaviour is of specifying a > > session that does not exist ? Is it intended that it should give > > information on all sessions combined, in which case missing the pregap > > is a bug that needs fixing ? > > Not sure, I'd have to investigate further, my memory on pregap/session > stuff is a bit faint. Session default is indeed 1, and by default only > that TOC information is displayed. > > > Or is it supposed to error out straight away ? If so, is there any other > > way cdrdao can read a .toc file for all sessions combined, or should I > > manually find a way to combine them ? > > You can use the option --driver generic-mmc:0x10000 > > The option (OPT_DRV_GET_TOC_GENERIC) disable the session filter after > the generic TOC read, i.e should you get the TOCs for all sessions. It only seems to paper over the error it shows before, but no behaviour changes. To clarify; using --session 9 (or any other non-existent session) does read all available sessions into one toc; but as said before, the bug is that it fails to detect the pregap of the first track. When reading the first session, it detects the pregap just fine. That's why I think it's more a bug than anything else really. I tested with CVS as you suggested (before I was using 1.2.2 on Fedora 9), and it shows: [thomas@ana cdrdao]$ dao/cdrdao msinfo -v 4Cdrdao version 1.2.3rc2 - (C) Andreas Mueller <an...@da...> Detected SG driver version: 3.5.27 SG: Maximum transfer length: 65536 /dev/sr0: Initiating SCSI command Inquiry /dev/sr0: SCSI command Inquiry (0x12) executed in 5 ms, status=0 /dev/sr0: Initiating SCSI command Mode Sense (10) /dev/sr0: SCSI command Mode Sense (10) (0x5a) executed in 1 ms, status=0 /dev/sr0: Initiating SCSI command Mode Sense (10) /dev/sr0: SCSI command Mode Sense (10) (0x5a) executed in 5 ms, status=0 Detected SG driver version: 3.5.27 SG: Maximum transfer length: 65536 /dev/sr0: Initiating SCSI command Inquiry /dev/sr0: SCSI command Inquiry (0x12) executed in 5 ms, status=0 /dev/sr0: PLEXTOR DVDR PX-810SA Rev: 1.00 Cannot read driver table from file "/usr/local/share/cdrdao/drivers" - using built-in table. /dev/sr0: Initiating SCSI command Mode Sense (10) /dev/sr0: SCSI command Mode Sense (10) (0x5a) executed in 0 ms, status=0 /dev/sr0: Initiating SCSI command Mode Sense (10) /dev/sr0: SCSI command Mode Sense (10) (0x5a) executed in 5 ms, status=0 Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000) /dev/sr0: Initiating SCSI command Rezero Unit /dev/sr0: SCSI command Rezero Unit (0x01) failed: Bad address. /dev/sr0: Initiating SCSI command Test Unit Ready /dev/sr0: SCSI command Test Unit Ready (0x00) executed in 1 ms, status=0 /dev/sr0: Initiating SCSI command Rezero Unit /dev/sr0: SCSI command Rezero Unit (0x01) failed: Bad address. /dev/sr0: Initiating SCSI command Read disc information /dev/sr0: SCSI command Read disc information (0x51) executed in 5 ms, status=0 /dev/sr0: Initiating SCSI command Read TOC /dev/sr0: SCSI command Read TOC (0x43) executed in 1 ms, status=0 /dev/sr0: Initiating SCSI command Read TOC /dev/sr0: SCSI command Read TOC (0x43) executed in 6 ms, status=2 /dev/sr0: Initiating SCSI command Read disc information /dev/sr0: SCSI command Read disc information (0x51) executed in 5 ms, status=0 /dev/sr0: Initiating SCSI command Read TOC /dev/sr0: SCSI command Read TOC (0x43) executed in 0 ms, status=0 /dev/sr0: Initiating SCSI command Read TOC /dev/sr0: SCSI command Read TOC (0x43) executed in 6 ms, status=2 msinfo: CD-R is not empty and not appendable Not sure if you can make anything from that. I tested the behaviour on my laptop as well and it's the same. It looks like, if I want an accurate multi-session TOC, I should assemble it myself from each of the sessions. Feel free to let me know if I'm missing something obvious. Thomas -- Careful stays and careless dies -- MOAP - Maintaining your projects since 2006 https://apestaart.org/moap/trac/ |
From: Denis L. <de...@po...> - 2009-05-25 11:24:49
|
On 05/24/2009 07:56 PM, Thomas Vander Stichele wrote: > To clarify; using --session 9 (or any other non-existent session) does > read all available sessions into one toc; but as said before, the bug is > that it fails to detect the pregap of the first track. When reading the > first session, it detects the pregap just fine. Hmm. I'm not sure on the pregap aspect yet. However yes looking at the code, the processing of the --session argument needs to be improved. Now the error message about the bogus toc data is a problem, and I think it causes a premature stop to the processing of the raw toc data (which may be why the pregap is not processed correctly). So it looks as though your CD doesn't use valid Red Book CD format. Is it a so-called "copy protected" CD ? What does 'cdrdao disk-info -v 3' show ? Even if the 2nd session contains data (such as a movie for example, I have several CDs like that), the TOC should still be present and correct. -denis |
From: Thomas V. S. <th...@ap...> - 2009-05-25 14:31:36
|
> On 05/24/2009 07:56 PM, Thomas Vander Stichele wrote: > > To clarify; using --session 9 (or any other non-existent session) does > > read all available sessions into one toc; but as said before, the bug is > > that it fails to detect the pregap of the first track. When reading the > > first session, it detects the pregap just fine. > > > Hmm. I'm not sure on the pregap aspect yet. However yes looking at the > code, the processing of the --session argument needs to be improved. Now > the error message about the bogus toc data is a problem, and I think it > causes a premature stop to the processing of the raw toc data (which may > be why the pregap is not processed correctly). > > So it looks as though your CD doesn't use valid Red Book CD format. Is > it a so-called "copy protected" CD ? Hi Denis, yes, it's a 'Copy Controlled' CD. The CD Is Das Capital - The Songwriting Genius of Luke Haines and The Auteurs. It's a good test disc for my ripper because it contains both a HTOA and a data track. I haven't yet found such a disc without copy control, feel free to suggest me one if you know of one. IIRC a 'copy controlled' CD is simply a cd where the second session only contains the additional session data, and none of the first session audio tracks. Is that correct ? > What does 'cdrdao disk-info -v 3' with CVS: [thomas@ana dao]$ ./cdrdao disk-info -v 3 --device /dev/sr0 Cdrdao version 1.2.3rc2 - (C) Andreas Mueller <an...@da...> Detected SG driver version: 3.5.27 /dev/sr0: PLEXTOR DVDR PX-810SA Rev: 1.00 Cannot read driver table from file "/usr/local/share/cdrdao/drivers" - using built-in table. Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000) /dev/sr0: SCSI command Rezero Unit (0x01) failed: Bad address. /dev/sr0: SCSI command Rezero Unit (0x01) failed: Bad address. That data below may not reflect the real status of the inserted medium if a simulation run was performed before. Reload the medium in this case. CD-RW : no Total Capacity : n/a CD-R medium : n/a Recording Speed : n/a CD-R empty : no Toc Type : CD-DA or CD-ROM Sessions : 2 Last Track : 12 Appendable : no > show ? Even if the 2nd session contains data (such as a movie for > example, I have several CDs like that), the TOC should still be present > and correct. > > -denis Does this tell you what you need to know ? Anything else I can provide you with ? Thanks Thomas -- - I love it when you take charge, you man you. - Was that a yes ? I ... I'm having trouble keeping track. -- Flumotion - the only way to stream! http://www.flumotion.net/ |
From: Denis L. <de...@po...> - 2009-05-25 14:51:43
|
On 05/25/2009 04:31 PM, Thomas Vander Stichele wrote: > yes, it's a 'Copy Controlled' CD. The CD Is Das Capital - The > Songwriting Genius of Luke Haines and The Auteurs. > > It's a good test disc for my ripper because it contains both a HTOA and > a data track. I haven't yet found such a disc without copy control, > feel free to suggest me one if you know of one. Well I think the very definition of "copy control" means it does have some crazy hack like HTOA. I have to admit I don't know much about HTOA, never had a chance to actually look at the raw TOC data of one... > IIRC a 'copy controlled' CD is simply a cd where the second session only > contains the additional session data, and none of the first session > audio tracks. Is that correct ? Not quite, there's nothing wrong with having multiple sessions, some including CD-ROM format of data. That's common, and cdrdao handles that just fine. The definition of a "copy protected" CD is very fuzzy, since this is somewhat biased towards Windows, but generally they master an audio CD that intentionally violates some of Red Book rules, knowing that most CD players will ignore the errors and keep playing the audio, while rippers tend to be much less tolerant. That concept has been pushed in various directions by different companies. I have a CD here that says 'copy protected', but all they did is slap a 2nd data session with an Windows autostart file, so it's merely an annoyance for windows users. > Does this tell you what you need to know ? Anything else I can provide > you with ? Ahem :-) Well if you wish to donate to the project, ship me one of those CDs (or a raw copy) so I can take a look :-) -denis |
From: Thomas V. S. <th...@ap...> - 2009-05-25 15:51:46
|
On Mon, 2009-05-25 at 16:51 +0200, Denis Leroy wrote: > On 05/25/2009 04:31 PM, Thomas Vander Stichele wrote: > > yes, it's a 'Copy Controlled' CD. The CD Is Das Capital - The > > Songwriting Genius of Luke Haines and The Auteurs. > > > > It's a good test disc for my ripper because it contains both a HTOA and > > a data track. I haven't yet found such a disc without copy control, > > feel free to suggest me one if you know of one. > > Well I think the very definition of "copy control" means it does have > some crazy hack like HTOA. I have to admit I don't know much about HTOA, > never had a chance to actually look at the raw TOC data of one... No, HTOA is completely according to red book standard. It just means that the first track has an index 00, and since CD players normally are supposed to start playing track 01 at index 01, it skips that part of the track. Artists use this to hide bonus tracks, for example. I have several normal CD's, not copy protected, no data tracks, 1 session, that have a HTOA. > > IIRC a 'copy controlled' CD is simply a cd where the second session only > > contains the additional session data, and none of the first session > > audio tracks. Is that correct ? > > Not quite, there's nothing wrong with having multiple sessions, some > including CD-ROM format of data. That's common, and cdrdao handles that > just fine. Yes; I was not talking about multiple sessions, I was talking about having a second session that specifically only mentions data added in the second session. Ie, writing a TOC that deliberately only contains the data tracks, none of the audio tracks from session 1. I'm not sure however how I validate this with the discs I have; I don't have a program other than crdao that reads or claims to read TOC's from individual sessions... > The definition of a "copy protected" CD is very fuzzy, since this is > somewhat biased towards Windows, but generally they master an audio CD > that intentionally violates some of Red Book rules, knowing that most CD > players will ignore the errors and keep playing the audio, while rippers > tend to be much less tolerant. That concept has been pushed in various > directions by different companies. I have a CD here that says 'copy > protected', but all they did is slap a 2nd data session with an Windows > autostart file, so it's merely an annoyance for windows users. > > > Does this tell you what you need to know ? Anything else I can provide > > you with ? > > Ahem :-) Well if you wish to donate to the project, ship me one of those > CDs (or a raw copy) so I can take a look :-) I'll have to see if that disc is still in print, I'll let you know :) Thomas -- There was no part of that which wasn't fun. -- savon - Saving your work to svn https://apestaart.org/thomas/trac/ |