Re: [Libcdio-devel] CD-TEXT documentation

[Rocky Bernstein]

On Mon, Feb 6, 2012 at 8:38 AM, Thomas Schmitt <address@hidden> wrote:

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

Great - will update later.

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

As I look at the information that is there, it seems to be about to encode
(from a low level or from the level of cue-sheets and Sony forms) and how
to decode CD Text information. The title cdtext.txt with the title CD-TEXT
Description suggests something broader than this.



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

I understand. I'm just suggesting that rather than describe things bottom
up, one might keep a human focus. That is rather than say Pack Type 0x86 is
like this, you'd say that the Disk Identification (Pack Type 0x86) is like
this. In my edits, I took an intermediate approach and kept the pack type
as in cdtext.txt, but added the human description in parenthesis. Again, I
think the convenience should be human centric, not a computer code centric.


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

xor 0xffff is exactly the same things a mod 2**16. You must be talking
about something else.


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