[Debburn-devel] CD-Extra issues

[Ralf Baechle]

On Fri, Dec 05, 2014 at 03:46:57PM +0100, Thomas Schmitt wrote:

> > Something in my analysis is not quite right though.  I've manually
> > decoded interleave as 0 but the "Interleaved files not (yet) supported."
> 
> It's not the Interleave Gap Size and File Unit Size of the
> root directory record, but the random bytes which it reads
> when interpreting the MP3 data as first directory record
> of the root directory list.
> 
> 
> > The first block of the 2nd session is 291114 / 0x4712a, that is the root dir
> > is located at offset 0x471dc - 0x4712a = 0xb2.  But for an fs built with
> > -C 0,0 (or without -C) the root dir is stored at 0x1c.  That's a difference
> > of 0x96 which is 150.  And 150 is the first argument to mkisofs -C
> > 150,291114.
> 
> Interesting observation.

I think I wasn't quite clear in my previous email -if I burn audio files
and .iso that way, the resulting CD is perfectly fine.

> The first argument of mkisofs option -C is supposed to be used
> with option -M, which loads an ISO directory tree for the purpose
> of adding more files to it.
> You did not use -M. So i assumed "150" was ignored.

So was I.  Now I'm wondering where to find a copy of the mkisofs source
code.  The maintainership situation of all the related tool is slightly
confusing, to say the least so I haven't found the one Authoritative
Source yet.

> The number 291114 is a prediction at what block the CD drive
> will start to write the next session. (A waste of several MB between
> the end of the previous session and the new start is normal.
> The CD drive decides about this.)
> 291114 was a correct prediction since you really found the primary
> volume descriptor at block 291114 + 16.
> 
> So it seems that mkisofs (genisoimage ?) took the parameter 150
> as additional offset for address pointers in the ISO image.

mkisofs on Fedora is a symlink (via /etc/alternatives) to genisoimage.

> If you are curious, try what happens if you prepare the audio part
> so that wodim -msinfo tells  150,something  but replace the 150
> by 0 when applying this reply to mkisofs/genisoimage.

The same idea had occured to me - then again the first pregap was
undesired anyway.  And I didn't have the time to try that yesterday.
Will try later tonight.

> Experiments for my own software:
> 
> - Do
>     xorriso -as cdrecord dev=/dev/sr0 -msinfo
>   or
>     cdrskin dev=/dev/sr0 -msinfo
>   return  150,something  too ?
> 
> - Does
>     xorriso -as mkisofs -o cd/mp3.iso -C 150,something -r -J cd/*.mp3
>   yield different results than
>     xorriso -as mkisofs -o cd/mp3.iso -C 0,something -r -J cd/*.mp3
> 
> (For burning one could use
>     xorriso -as cdrecord dev=/dev/sr0 cd/mp3.iso
>  or
>     cdrskin dev=/dev/sr0 cd/mp3.iso
> )
> 
> I will try these experiments myself after learning to fake a .toc
> that is digestible for cdrdao.
> Nevertheless i would also be interested in learning about your
> experience with xorriso and cdrskin.

Faking the TOC - easy enough.  Here's my TOC with all the CD_TEXT bits
removed that are making this test case more complicated.

< ----------------------------------------------------- >
CD_ROM_XA

TRACK AUDIO
PREGAP 0:2:0
AUDIOFILE "cd/track-01.wav" 0

TRACK AUDIO
PREGAP 0:2:0
AUDIOFILE "cd/track-02.wav" 0

TRACK AUDIO
PREGAP 0:2:0
AUDIOFILE "cd/track-03.wav" 0

< ----------------------------------------------------- >

Repeat the TRACK_AUDIO block for as often as desired.  Burning this
with cdrdao will result in a CD with the msinfo 150,xxx block offsets
while if the PREGAP line for the first track is removed the msinfo will
become 0,xxx.

And here the wav files to go with it:

for i in {1..3}; do
	sox -r 44.1k -e signed -b 16 -c 2 --type raw /dev/urandom \
		track-01.wav trim 0 $(($RANDOM / 1000 + 30))

Shouldn't bring to too deep into legal trouble withe GEMA ;-)

  Ralf