libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] CD-Text patches


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] CD-Text patches
Date: Thu, 08 Dec 2011 20:40:07 +0100

Hi,

> > Has this been tested with an audio CD player ?

> No. I don't have one ;)

Well, i am totally non-audiophile. The speakers of my computer
are only serving as bookends for my backup DVDs and BDs.

But i should probably try to get an old CD player.
... and a DVD video player for the case that wisdom about UDF drops
from heaven. (It is darn complicated and cannot do more than ISO 9660
with Rock Ridge, but it is standard for entertainment DVDs and BDs.)


> The trailing 0 is actually correct according to the spec and was caused
> by the Sony tool. I will alter libcdios code to compensate it.

spec is the .doc stuff from the Sony tool ?

wodim hates the trailing zero:
  wodim: Inconsistent CD-Text file 'frog.cdt' not a multiple of pack length
  wodim: Cannot use 'frog.cdt' as CD-Text file.

cdrskin currently does too.
But if you say that 33 * 18 bytes + 1 zero are ok, then i will
let cdrskin and libburn ignore that trailing zero.

Nevertheless, we should try to find out whether this zero is only for
the largest CD burner of the world, which is not an MMC machine,
obviously (see doc 2 of the Sony specs.) At least MMC does not mention
U-matic tapes as essential component of the writing process. :)))

In what doc-number is that trailing zero mentioned ?


> > Why is the number of the first track 2 and not 1 ?
> > Did you cause this by input to the Sony tool ?

> Yes. I did it on purpose.

What would be a reason to state that the track 2 is the first one ?

I see that there are three titles in frog.cdt.
Will the reader attribute them to disc, track 2 and track 3 ?
What will be shown for track 1 ?


> > - What input caused these two Disc Identification packs ?
> My input was 1..(10 0s)...2. The second Pack was necessary for the
> trailing 0x00.

Ahum. Any idea what "100000000002" means ?


> > - Why does the copyright byte differ in both 0x8f groups ?

> Because of my input. I wanted to test how independent the Blocks are.

This seems to contradict the prescription that blocks group languages.
How can a piece of music be copyrighted in german language and
not copyrighted in english ?
(Where to meet the Sony engineers for a drink and a sneaky interrogation ?)


> > [type 0x87 in cdtext.cdt and frog.cdt]
> CDRWIN or Sony: Which one is to trust?

Normally i'd say Sony ... if there wasn't above copyright quirk, which
makes me mistrusting about the rigidity of the tool.
My cookbook now says about 0x87:
 "The two binary bytes may or may not be repeated at the start of each pack."

> But you have to make a decision for libburn ;)

I will probably implement Sony style ... and a compile time option
to switch to CDRWIN style. Then i will wait for somebody to complain.
Try-and error seems to be the only way to find insight.


> What I don't understand is why there are not DISC_ID fields. I inputted
> some garbage for them.

Ain't DISC_ID pack type 0x86 ? Those with the "100000000002" ?

FROSCH.TEXT has:
  Catalog Number =            100000000002
  Disc Information 01 =       Ein paar Infos

Obviously CDIO_CDTEXT_DISCID comes from "Catalog Number".

In Doc 4 i see:
"Disc Information (26) consists of four separate tags, and may be used as
 a supplementary information. The use of this field is completely up to
 each record companies. The information in parenthesis below is the usage
 by Sony.
 Disc Info. 01 Up to 32 characters of 8859-1 characters.
   (Sales companys name or its abbreviated code)
  Disc Info. 02 Up to 32 characters of 8859-1 characters.
   (Records product number)
  Disc Info. 03 Up to 32 characters of 8859-1 characters.
   (Master disc number)
  Disc Info. 04 Up to 8 characters of 8859-1 characters.
   (Creation date of the master disc).
"
So this is not a CD-TEXT pack type.


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]