cdrdao-devel

Re: [Cdrdao-devel] What causes index marks to be lost?

[j t <ma...@gm...>]

On Sat, Jun 6, 2009 at 6:05 PM, Thomas Vander
Stichele<th...@ap...> wrote:
> On Sun, 2009-05-31 at 00:12 +0100, j t wrote:
>> Hi,
>>
>> I'm trying to use "cdrdao read-toc audiocd.toc" to create a toc-file
>> for an audio cd which contains Q sub-channel index marks (the cd is
>> listed at http://musicbrainz.org/show/cdtoc/?cdtocid=57630).
>>
>
> Hi,
>
> have you tried with various drivers ? I've noticed that some of the
> drivers get me more accurate index scanning than others, even if my
> drive isn't detected specifically by cdrdao.
>
> For example, my desktop has a Plextor DVDR PX-810SA 1.00.
>
> The drivers that get the pregaps right:
> generic-mmc, generic-mmc-raw, ricoh-mp6200
>
> The drivers that get them wrong:
> plextor, toshiba, taiyo-yuden
>
> The ones that don't find any indexes:
> teac-cdr55, yamaha-cdr10x
>
> The ones that don't find ISRC:
> plextor-scan, sony-cdu920, sony-cdu948
>
> My laptop has a MATSHITA DVD/CDRW UJDA775; on that machine, the generic
> drivers get lots of CRC errors on the Q channels, but the plextor one
> works fine.
>
> I suggest you try with various drivers and compare with known good
> output (from another program, like EAC)

Thank you, Thomas, you are correct.

I tried the same command with different drivers, and the results (i.e.
whether the driver could detect the additional index marks) are:

--driver cdd2600 FAIL
--driver plextor SUCCESS
--driver plextor-scan FAIL
--driver generic-mmc FAIL
--driver generic-mmc-raw FAIL
--driver ricoh-mp6200 FAIL
--driver yamaha-cdr10x FAIL
--driver teac-cdr55 FAIL
--driver sony-cdu920 FAIL
--driver sony-cdu948 FAIL
--driver taiyo-yuden SUCCESS
--driver toshiba SUCCESS

This is for a MATSHITA DVD-RAM UJ-842 (in a Lenovo T60 Thinkpad).

Again, thank you for your help,

Jaime

[Cdrdao-devel] scsci host num / busno is getting to high at wodim and cdrdao

[Wolfgang E. <we...@x-...>]

Hi!

As described in

https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/388436

we have a very annoying bug / problem in cdrkit & cdrdao.
Maybe you could help us at finding a proper solution...

The bug report:

Hi!

We are using Ubuntu 8.04.2 server with wodim 9:1.1.6-1ubuntu6 and cdrdao 
1:1.2.2-8ubuntu3. We have a cd and dvd burning robot connected to our 
server. The robots cd/dvd drives are ide drives that are connected via a 
ide <-> firewire changer. So the drives are recognized as /dev/sr* an 
can be used like normal internal drives.

Now we got the following problem: When we turn of the robot (and in fact 
the power source for the drives) and turn it on again, the scsi busno is 
increased by one. After some time this can lead to very high numbers 
like 277 or so. If we do a wodim --scanbus we can still see the drives, 
but wodim and cdrdao can't use them any more. At busno >= 256 we get 
this error message:

Cdrdao version 1.2.2 - (C) Andreas Mueller <an...@da...>
  SCSI interface library - (C) Joerg Schilling
  Paranoia DAE library - (C) Monty

Check http://cdrdao.sourceforge.net/drives.html#dt 
<http://cdrdao.sourceforge.net/drives.html#dt> for current driver tables.

ERROR: Cannot open SCSI device '/dev/sr1': Illegal value for busno, 
target or lun '256,0,0'
...

The same problem seems to occur with all usb or firewire connected 
writers/drives.

So my question is how to solve this... I looked at the source code and 
found a maximum number in some lib, but also some arrays are allocated 
with that number - so maybe it is a bad idea to change it... A reboot of 
course helps, but that's really a bad solution.

I've found a kernel patch at [1] from Ben Collins which was intended to 
solve our problem. The final version of the patch can be found at [2]. I 
tried it and it worked well until a drive hung up and I got some sort of 
NULL Pointer Error. Then the whole system hung until a cold start.

In [3] H. Peter Anvin states that he doesn't like the patch because of 
the number allocation scheme. I certainly agree his comment but how can 
we solve our problem? Is it really a kernel issue or is it an issue of 
cdrkit (wodim/cdrecord/...) cause it has a maximum value while the 
kernel has none (only at overflow)? Is there any way to patch the lib 
myself (cause i'm not very familiar with C and linux libraries)?

If you need any further information or outputs please feel free to 
contact me! Thanks in advance!

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0402.3/1052.html 
<http://lkml.indiana.edu/hypermail/linux/kernel/0402.3/1052.html>
[2] http://lkml.indiana.edu/hypermail/linux/kernel/0402.3/1403.html 
<http://lkml.indiana.edu/hypermail/linux/kernel/0402.3/1403.html>
[3] http://lkml.indiana.edu/hypermail/linux/kernel/0402.3/1323.html 
<http://lkml.indiana.edu/hypermail/linux/kernel/0402.3/1323.html>

-----

As I found out in libusal/scsi-linux-sg.c:165 wodim stops at 1256: 
#define MAX_SCG 1256 /* Max # of SCSI controllers */

cdrdao stops at 256, defined in scsilib/libscg/scsi-linux-sg.c:147

I could raise these numbers but it is still a problem of "where is the 
end?" or how much memory is additionally consumed for the arrays which 
are allocated with these constants.

----


Best regards
Wolfgang Eibner

-- 
---------------------------------------
Wolfgang Eibner
e: we...@x-...
t: +43 732 773 142 - 28
m: +43 676 74 81 350
f: +43 732 773 142 - 24
X-Net Services / Technologies GmbH
Elisabethstrasse 1
4020 Linz
Austria
Firmenbuchnummer: 212504g / FN296035x
Firmenbuchgericht: Landesgericht Linz
---------------------------------------
--

[Cdrdao-devel] START value for index 0 on toc extraction off by one error ?

[Thomas V. S. <th...@ap...>]

Hi,

I noticed that cdrdao's toc extraction always lists the length of the
pregap as one frame shorter than EAC.  For example, on Muse's Black
Holes and revelations:

- cdrdao lists, for track 11:
// Track 11
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC "GBAHT0500600"
FILE "data.wav" 39:23:53 06:07:22
START 00:00:37

- EAC has: 0:00:00.38 in the ui

Is it possible cdrdao has an off-by-one error here ? How can I verify
whether it's cdrdao or EAC getting it wrong ?

Thomas



-- 
I looked up at Anna
She turned back to look at me
It's best to kill the ones that matter
Render blind the ones that see
--
GStreamer - bringing multimedia to your desktop
http://gstreamer.freedesktop.org/

Re: [Cdrdao-devel] What causes index marks to be lost?

[Thomas V. S. <th...@ap...>]

On Sun, 2009-05-31 at 00:12 +0100, j t wrote:
> Hi,
> 
> I'm trying to use "cdrdao read-toc audiocd.toc" to create a toc-file
> for an audio cd which contains Q sub-channel index marks (the cd is
> listed at http://musicbrainz.org/show/cdtoc/?cdtocid=57630).
> 

Hi,

have you tried with various drivers ? I've noticed that some of the
drivers get me more accurate index scanning than others, even if my
drive isn't detected specifically by cdrdao.

For example, my desktop has a Plextor DVDR PX-810SA 1.00.

The drivers that get the pregaps right:
generic-mmc, generic-mmc-raw, ricoh-mp6200

The drivers that get them wrong:
plextor, toshiba, taiyo-yuden

The ones that don't find any indexes:
teac-cdr55, yamaha-cdr10x

The ones that don't find ISRC:
plextor-scan, sony-cdu920, sony-cdu948

My laptop has a MATSHITA DVD/CDRW UJDA775; on that machine, the generic
drivers get lots of CRC errors on the Q channels, but the plextor one
works fine.

I suggest you try with various drivers and compare with known good
output (from another program, like EAC)

Thomas

-- 
I work all day and I won't fight
when it feels right then it's wrong
now the fireworks in me are all gone
--
GStreamer - bringing multimedia to your desktop
http://gstreamer.freedesktop.org/

Re: [Cdrdao-devel] What causes index marks to be lost?

[j t <ma...@gm...>]

On Sun, May 31, 2009 at 12:12 AM, j t <ma...@gm...> wrote:
> (Could it
> be something to do with the fact that the first machine uses parallel
> ATA drives, while the second machine uses serial ATA drives?)
>
> Thanks, Jaime :-)

Interesting - I've just tried:

icedax dev=/dev/cdrom -vall cddb=0 -B -Owav

on the second machine, and it correctly detects the index points in
track 02 and track 07. Perhaps it's not a hardware limitation after
all.

Jaime

[Cdrdao-devel] What causes index marks to be lost?

[j t <ma...@gm...>]

Hi,

I'm trying to use "cdrdao read-toc audiocd.toc" to create a toc-file
for an audio cd which contains Q sub-channel index marks (the cd is
listed at http://musicbrainz.org/show/cdtoc/?cdtocid=57630).

I have 2 machines - they both run Debian Lenny. The 1st machine
produces the following toc:

CD_DA


// Track 1
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
SILENCE 00:00:33
FILE "data.wav" 0 02:21:37
START 00:00:33


// Track 2
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
FILE "data.wav" 02:21:37 11:43:10
INDEX 04:08:35
INDEX 08:54:05


// Track 3
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
FILE "data.wav" 14:04:47 04:29:28
...
...



The 2nd machine, however, produces the following toc:

CD_DA


// Track 1
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
SILENCE 00:00:33
FILE "data.wav" 0 02:21:37
START 00:00:33


// Track 2
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC "400000000000"
FILE "data.wav" 02:21:37 11:43:10


// Track 3
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
FILE "data.wav" 14:04:47 04:29:28
...
...

The toc-file produced by the 2nd machine is missing the 2 index marks
for track 2. Does anyone know why this happens, and whether there is
anything I can do to stop the index marks from disappearing? (Could it
be something to do with the fact that the first machine uses parallel
ATA drives, while the second machine uses serial ATA drives?)

Thanks, Jaime :-)

Re: [Cdrdao-devel] cdrdao and session reading

[Thomas V. S. <th...@ap...>]

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/

Re: [Cdrdao-devel] cdrdao and session reading

[Denis L. <de...@po...>]

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

Re: [Cdrdao-devel] cdrdao and session reading

[Thomas V. S. <th...@ap...>]

> 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/

Re: [Cdrdao-devel] cdrdao and session reading

[Denis L. <de...@po...>]

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

Re: [Cdrdao-devel] cdrdao and session reading

[Thomas V. S. <th...@ap...>]

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/

Re: [Cdrdao-devel] cdrdao and session reading

[Denis L. <de...@po...>]

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

[Cdrdao-devel] cdrdao and session reading

[Thomas V. S. <th...@ap...>]

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/

[Cdrdao-devel] cdrdao 1.2.3rc2

[Denis L. <de...@po...>]

http://www.poolshark.org/src/cdrdao-1.2.3rc2.tar.bz2

I managed to fix a number of Cygwin issues. It compiles on cygwin from 
the CVS trunk, but I had some problems compiling on cygwin from the 
tarball, not sure why. I've added most of the patches submitted. I have 
some code for native interfaces for Windows and OpenSolaris, but not 
ready yet for inclusion...

-denis

Re: [Cdrdao-devel] Problems compiling cdrdao 1.2.3rc1 for Cygwin

[Denis L. <de...@po...>]

Denis Leroy wrote:
> Hi Mitch,
> 
> Mitch Wiygul wrote:
>> Cowo's solution is better than mine.  Please use it instead. 
> 
> I'm sorry, what solution are you referring to ?

Hmm, never mind that :-)

Re: [Cdrdao-devel] Problems compiling cdrdao 1.2.3rc1 for Cygwin

[Denis L. <de...@po...>]

Hi Mitch,

Mitch Wiygul wrote:
> Cowo's solution is better than mine.  Please use it instead. 

I'm sorry, what solution are you referring to ?

> But whoever named a method 'min' in the first place should be subject to 
> public ridicule.  The mathematical function is widely enough used that 
> it has first rights to the name.

Agreed :-) the offending define comes from the cdparanoia code. I've 
renamed them.

> Also, it looks like the SOURCE_SCSI_DEVICE that I mentioned should be 
> replaced by some use of a structure member named sourceScsiDevice, but 
> I'm not quite sure what the exact right way to do it is.

I'm looking into it.

Re: [Cdrdao-devel] Problems compiling cdrdao 1.2.3rc1 for Cygwin

[Mitch W. <fmw...@ya...>]

Cowo's solution is better than mine.  Please use it instead. 

But whoever named a method 'min' in the first place should be subject to 
public ridicule.  The mathematical function is widely enough used that 
it has first rights to the name.

Also, it looks like the SOURCE_SCSI_DEVICE that I mentioned should be 
replaced by some use of a structure member named sourceScsiDevice, but 
I'm not quite sure what the exact right way to do it is.


Mitch

Re: [Cdrdao-devel] Problems compiling cdrdao 1.2.3rc1 for Cygwin

[Denis L. <de...@po...>]

Mitch Wiygul wrote:
> Denis,
> 
> I ran into a couple of problems compiling cdrdao 1.2.3rc1 on Cygwin.
> The first one comes from Cygwin somehow defining min in a way that 
> cdrdao doesn't like.  Or maybe it comes from header files  coming in an 
> infelicitous order in Cygwin.  Anyhow, the attached file cygmin.patch 
> makes the compile error go away.
> The second problem is that SCSI_SOURCE_DEVICE is undefined on line 2200 
> of main.cc.  I couldn't find SCSI_SOURCE_DEVICE anywhere else in cdrdao 
> 1.2.3rc1 source, in Cygwin include files, Linux source code, Slackware 
> 12.1  include files, or a Google search.
> Finally, going back to cdrdao 1.2.2, I never was able to get device 
> locking to work with Cygwin on Windows XP.  As I recall, the Windows 
> calls never would let me get exclusive access to the drive.

Mitch, thanks for the patch. I'll work on another release candidate this 
week.

If someone has time for this, I think it would also be an interesting 
experiment to try cross-compiling cdrdao for Windows on Linux using MinGW.

Re: [Cdrdao-devel] Problems compiling cdrdao 1.2.3rc1 for Cygwin

[Giuseppe \Cowo\ C. <co...@lu...>]

Mitch Wiygul wrote:
> Denis,
> 
> I ran into a couple of problems compiling cdrdao 1.2.3rc1 on Cygwin.
> The first one comes from Cygwin somehow defining min in a way that
> cdrdao doesn't like.  Or maybe it comes from header files  coming in an
> infelicitous order in Cygwin.  Anyhow, the attached file cygmin.patch
> makes the compile error go away.

windows.h #defines min and max as macros, thus leading to a mismatch with
std::min and std::max
Need to #define NOMINMAX somewhere before including windows.h

> The second problem is that SCSI_SOURCE_DEVICE is undefined on line 2200
> of main.cc.  I couldn't find SCSI_SOURCE_DEVICE anywhere else in cdrdao
> 1.2.3rc1 source, in Cygwin include files, Linux source code, Slackware
> 12.1  include files, or a Google search.
> Finally, going back to cdrdao 1.2.2, I never was able to get device
> locking to work with Cygwin on Windows XP.  As I recall, the Windows
> calls never would let me get exclusive access to the drive.

That's when I said "I will look into that". Maybe now it's time to REALLY look
into that :-)

-- 
        Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net
-<! Non c'e' niente da dire in proposito. Tutto quello che uno deve fare e'
  colpire i tasti giusti al momento giusto, e lo strumento suona da solo. !>-
                                J.S. Bach

[Cdrdao-devel] Problems compiling cdrdao 1.2.3rc1 for Cygwin

[Mitch W. <fmw...@ya...>]

Denis,

I ran into a couple of problems compiling cdrdao 1.2.3rc1 on Cygwin. 

The first one comes from Cygwin somehow defining min in a way that 
cdrdao doesn't like.  Or maybe it comes from header files  coming in an 
infelicitous order in Cygwin.  Anyhow, the attached file cygmin.patch 
makes the compile error go away. 

The second problem is that SCSI_SOURCE_DEVICE is undefined on line 2200 
of main.cc.  I couldn't find SCSI_SOURCE_DEVICE anywhere else in cdrdao 
1.2.3rc1 source, in Cygwin include files, Linux source code, Slackware 
12.1  include files, or a Google search. 

Finally, going back to cdrdao 1.2.2, I never was able to get device 
locking to work with Cygwin on Windows XP.  As I recall, the Windows 
calls never would let me get exclusive access to the drive.

Mitch

Re: [Cdrdao-devel] cdrdao 1.2.3rc1 : call for testing/patches

[Edgar F. <ef...@ma...>]

> I'd like to release cdrdao 1.2.3 in a few days, so I'm looking for 
> testing feedback as well as any patches people might have.
In July 2007, I posted a set of several patches, including native drivers for OS X, NetBSD and Irix. Woud you like to consider them=

[Cdrdao-devel] cdrdao 1.2.3rc1 : call for testing/patches

[Denis L. <de...@po...>]

I'd like to release cdrdao 1.2.3 in a few days, so I'm looking for 
testing feedback as well as any patches people might have.

Release candidate tarball:

http://www.poolshark.org/src/cdrdao-1.2.3rc1.tar.bz2


The changelog is mainly bug and compile fixes coming for the Fedora, 
OpenSUSE and Ubuntu packages. A couple of new features

- rewritten native SG interface for Linux. All Linux distro packagers 
should compile cdrdao on the native SG interface (using 
--without-libscg) instead of using the libscg interface (which has 
scanning and device access issues).

- gcdmaster now uses gconf to store preferences and has a Preferences 
dialog to configure its temporary directory

[Cdrdao-devel] cdrdao 1.2.3rc1 : call for testing/patches

[Denis L. <de...@po...>]

I'd like to release cdrdao 1.2.3 in a few days, so I'm looking for 
testing feedback as well as any patches people might have.

Release candidate tarball:

http://www.poolshark.org/src/cdrdao-1.2.3rc1.tar.bz2


The changelog is mainly bug and compile fixes coming for the Fedora, 
OpenSUSE and Ubuntu packages. A couple of new features

- rewritten native SG interface for Linux. All Linux distro packagers 
should compile cdrdao on the native SG interface (using 
--without-libscg) instead of using the libscg interface (which has 
scanning and device access issues).

- gcdmaster now uses gconf to store preferences and has a Preferences 
dialog to configure its temporary directory

Re: [Cdrdao-devel] OS level device locking under Cygwin

[Giuseppe \Cowo\ C. <co...@lu...>]

Mitch Wiygul wrote:
> I've been trying to get the device locking working under Cygwin on 
> Windows XP.
> 
> I get the 'Unable to determine drive letter for device...' message 
> whenever I run cdrdao 1.2.2 under Cygwin.  It turns out that the call to 
> CreateFile is failing with error code 32, a sharing violation. 
> 
> I've tried to determine whether any other process has a handle open on 
> the drive by using Sysinternals' Process Explorer but didn't find 
> anything. 
> 
> My system has two burners in it; the same thing happens with both of 
> them.  The CreateFile call only fails for the drive that has a disc in 
> it (the one I want to burn with); it works for the empty drive.
> 
> Is this a known bug or does anyone have any hints? 

Twas me who wrote this code, long long time ago :-)
However I only tested it under windows 2000. I can setup a cygwin environment 
and give it a try but I make no promises on the timing.

-- 
         Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net
-<! Non c'e' niente da dire in proposito. Tutto quello che uno deve fare e'
   colpire i tasti giusti al momento giusto, e lo strumento suona da solo. !>-
                                 J.S. Bach

[Cdrdao-devel] OS level device locking under Cygwin

[Mitch W. <fmw...@ya...>]

I've been trying to get the device locking working under Cygwin on 
Windows XP.

I get the 'Unable to determine drive letter for device...' message 
whenever I run cdrdao 1.2.2 under Cygwin.  It turns out that the call to 
CreateFile is failing with error code 32, a sharing violation. 

I've tried to determine whether any other process has a handle open on 
the drive by using Sysinternals' Process Explorer but didn't find 
anything. 

My system has two burners in it; the same thing happens with both of 
them.  The CreateFile call only fails for the drive that has a disc in 
it (the one I want to burn with); it works for the empty drive.

Is this a known bug or does anyone have any hints? 

Thanks,

Mitch