libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] CD-TEXT documentation


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] CD-TEXT documentation
Date: Mon, 06 Feb 2012 14:38:39 +0100

Hi,

> One small thing I've noticed is that there is mention to mm5r03.pdf
> and that is not in the references.

Good point. I have looked up the equivalent spots in MMC-3:

mmc5r03c.pdf, table 490 TOC Track Descriptor Format, Q Sub-channel
=>
mmc3r10g.pdf, table 237 TOC Track Descriptor Format, Q Sub-channel

mmc5r03.pdf 4.2.3.7.4
=>
mmc3r10g.pdf 4.2.3.6.3


> Overall the cdtext.txt feels to me like the audience is a computer
> rather than a person. 

It is a description for developing CD-TEXT software.
Goal was to collect everything that is known and can be confirmed.


> Instead, I think it better to assume the audience are humans.

Well, man cdrskin explains some user aspects of CD-TEXT.
  http://scdbackup.webframe.org/man_1_cdrskin.html
The libburn API description mentions CD-TEXT with several calls:
  http://libburnia-project.org/browser/libburn/trunk/libburn/libburn.h

I simply lack of any user experience with audio CDs and/or CD-TEXT.
I can compose the packs, i can write them, i can read them, i can parse
them, but whether and how they work on a CD player: no clue.


> So I find it more user friendly to say you can store information
> about 8 languages rather than say there is a limit on 8 blocks.

Agreed.


> The same kind of thing with mentions of xor'ing 0xffff. That is
> C-centric computer jargon. The intent is that there's a 16-bit number
> there, that's what I think the designers were interested in. So it is
> equally valid to use a modulo 2**16 or if (x > 2**16) if the language
> you have doesn't provide xor.

I am currently not aware of the mathematical reason for the final
bit inversion of the division residue. It is not equivalent to modulo
alone (that would be and-ing, rather than xor-ing).
In the model of polynoms there would be a subtraction or addition involved.

To my knowledge the CD-TEXT CRC algorithm differs only by this final
bit inversion from the CRC algorithm that is mentioned in ECMA-167 7.2.6
for UDF descriptor tags.
The ECMA-167 example {0x70, 0x6a, 0x77} yields division residue 0x3299 and
CD-TEXT CRC 0xcd66. ECMA-167 predicts 0x3299.


Have a nice day :)

Thomas




reply via email to

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