On Mon, Feb 6, 2012 at 8:38 AM, Thomas Schmitt <[email protected]> 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 > > >
