Updated documentation of CD-TEXT pack types 0x88 and 0x89
This commit is contained in:
parent
d61f99ba93
commit
a784d0c4e7
@ -430,7 +430,7 @@ The first byte of each pack tells the pack type (text meaning):
|
|||||||
0x87 = text-and-binary: Genre Identification
|
0x87 = text-and-binary: Genre Identification
|
||||||
0x88 = binary: Table of Content information
|
0x88 = binary: Table of Content information
|
||||||
0x89 = binary: Second Table of Content information
|
0x89 = binary: Second Table of Content information
|
||||||
(0x8a to 0x8c are reserved. 0x8d is "Reserved for content provider only".)
|
(0x8a to 0x8c are reserved.)
|
||||||
0x8d = Closed Information
|
0x8d = Closed Information
|
||||||
0x8e = UPC/EAN code of the album and ISRC code of each track
|
0x8e = UPC/EAN code of the album and ISRC code of each track
|
||||||
0x8f = binary: Size Information of the Block
|
0x8f = binary: Size Information of the Block
|
||||||
@ -455,8 +455,9 @@ A text may span over several packs. Unused characters in a pack are used for
|
|||||||
the next text of the same pack type. If no text of the same type follows,
|
the next text of the same pack type. If no text of the same type follows,
|
||||||
then the remaining text bytes are set to 0.
|
then the remaining text bytes are set to 0.
|
||||||
|
|
||||||
The CRC algorithm uses divisor 0x11021 and is known as CRC-16-CCITT.
|
The CRC algorithm uses divisor 0x11021. The resulting 16-bit residue of the
|
||||||
MMC-3 says: "All bits shall be inverted."
|
polynomial division gets exored with 0xffff and written as big-endian
|
||||||
|
number to bytes 16 and 17 of the pack.
|
||||||
|
|
||||||
|
|
||||||
The text packs are grouped in up to 8 blocks of at most 256 packs. Each block
|
The text packs are grouped in up to 8 blocks of at most 256 packs. Each block
|
||||||
@ -478,12 +479,9 @@ Pack type 0x86 (Disc Identification) is documented by Sony as "Catalog Number:
|
|||||||
(use ASCII Code) Catalog Number of the album". So it is not really binary
|
(use ASCII Code) Catalog Number of the album". So it is not really binary
|
||||||
but might be non-printable.
|
but might be non-printable.
|
||||||
|
|
||||||
Type 0x87 seems to contain 2 binary bytes and 10 bytes of 0-terminated
|
Type 0x87 contains 2 binary bytes and 10 or 12 bytes of 0-terminated cleartext.
|
||||||
cleartext.
|
The two binary bytes may or may not be repeated at the start of the follow-up
|
||||||
The two binary bytes may or may not be repeated at the start of each pack.
|
packs of type 0x87. They form a big-endian index to the following list.
|
||||||
They form a big-endian index to the following list (from libcdio source, which
|
|
||||||
learned it from cdrecord source, stating "Genre codes from Enhanced CD
|
|
||||||
Specification page 21").
|
|
||||||
0x0000 = "Not Used"
|
0x0000 = "Not Used"
|
||||||
0x0001 = "Not Defined"
|
0x0001 = "Not Defined"
|
||||||
0x0002 = "Adult Contemporary"
|
0x0002 = "Adult Contemporary"
|
||||||
@ -512,12 +510,56 @@ Specification page 21").
|
|||||||
0x0019 = "Sound Effects"
|
0x0019 = "Sound Effects"
|
||||||
0x001a = "Spoken Word"
|
0x001a = "Spoken Word"
|
||||||
0x001b = "World Music"
|
0x001b = "World Music"
|
||||||
Sony documents the cleatext part as "Genre information that would supplement
|
Sony documents the cleartext part as "Genre information that would supplement
|
||||||
the Genre Code, such as 'USA Rock music in the 60s'".
|
the Genre Code, such as 'USA Rock music in the 60s'".
|
||||||
|
|
||||||
Unclear yet: 0x88 = Table of Content information
|
Pack type 0x88 records information from the CDs Table of Content, as of
|
||||||
|
READ PMA/TOC/ATIP Format 0010b (mmc5r03c.pdf, table 490 TOC Track Descriptor
|
||||||
|
Format, Q Sub-channel).
|
||||||
|
The first pack records in its payload bytes:
|
||||||
|
0 : PMIN of POINT A1 = First Track Number
|
||||||
|
1 : PMIN of POINT A2 = Last Track Number
|
||||||
|
2 : unknown, 0 in Sony example
|
||||||
|
3 : PMIN of POINT A2 = Start position of Lead-Out
|
||||||
|
4 : PSEC of POINT A2 = Start position of Lead-Out
|
||||||
|
5 : PFRAME of POINT A2 = Start position of Lead-Out
|
||||||
|
6 to 11 : unknown, 0 in Sony example
|
||||||
|
The following packs record in groups of 3 bytes PMIN, PSEC, PFRAME of the POINT
|
||||||
|
of the lowest track number to the POINT of the highest track number (max 63h).
|
||||||
|
The payload of the last pack is padded by 0s.
|
||||||
|
The Sony .TOC example:
|
||||||
|
A0 01
|
||||||
|
A1 14
|
||||||
|
A2 63:02:18
|
||||||
|
01 00:02:00
|
||||||
|
02 04:11:25
|
||||||
|
03 08:02:50
|
||||||
|
04 11:47:62
|
||||||
|
...
|
||||||
|
13 53:24:25
|
||||||
|
14 57:03:25
|
||||||
|
yields
|
||||||
|
88 00 23 00 01 0e 00 3f 02 12 00 00 00 00 00 00 12 00
|
||||||
|
88 01 24 00 00 02 00 04 0b 19 08 02 32 0b 2f 3e 67 2d
|
||||||
|
...
|
||||||
|
88 0d 27 00 35 18 19 39 03 19 00 00 00 00 00 00 ea af
|
||||||
|
|
||||||
Unclear yet: 0x89 = Second Table of Content information
|
Pack type 0x89 is yet quite unclear. Especially what the information shall
|
||||||
|
mean to the user of the CD. The time points in the Sony example are in the
|
||||||
|
time range of the tracks with the numbers that are given before the time
|
||||||
|
points:
|
||||||
|
01 02:41:48 01 02:52:58
|
||||||
|
06 23:14:25 06 23:29:60
|
||||||
|
07 28:30:39 07 28:42:30
|
||||||
|
13 55:13:26 13 55:31:50
|
||||||
|
yields
|
||||||
|
89 01 28 00 01 04 00 00 00 00 02 29 30 02 34 3a f3 0c
|
||||||
|
89 06 29 00 02 04 00 00 00 00 17 0e 19 17 1d 3c 73 92
|
||||||
|
89 07 2a 00 03 04 00 00 00 00 1c 1e 27 1c 2a 1e 72 20
|
||||||
|
89 0d 2b 00 04 04 00 00 00 00 37 0d 1a 37 1f 32 0b 62
|
||||||
|
The track numbers are stored in the track number byte of the packs. The two
|
||||||
|
time points are stored in byte 6 to 11 of the payload. Byte 0 of the payload
|
||||||
|
seems to be a sequential counter. Byte 1 always 4 ? Byte 2 to 5 always 0 ?
|
||||||
|
|
||||||
Type 0x8d is documented by Sony as "Closed Information: (use 8859-1 Code)
|
Type 0x8d is documented by Sony as "Closed Information: (use 8859-1 Code)
|
||||||
Any information can be recorded on disc as memorandum. Information in this
|
Any information can be recorded on disc as memorandum. Information in this
|
||||||
@ -530,15 +572,13 @@ Type 0x8f summarizes the whole list of text packs of a block.
|
|||||||
So there is one group of three 0x8f packs per block.
|
So there is one group of three 0x8f packs per block.
|
||||||
Nevertheless each 0x8f group tells the highest sequence number and the
|
Nevertheless each 0x8f group tells the highest sequence number and the
|
||||||
language code of all blocks.
|
language code of all blocks.
|
||||||
The payload bytes of three 0x8f packs form a 36 byte record.
|
The payload bytes of three 0x8f packs form a 36 byte record. The track number
|
||||||
|
bytes of the three packs have the values 0, 1, 2.
|
||||||
Byte :
|
Byte :
|
||||||
0 : Character code:
|
0 : Character code:
|
||||||
0x00 = ISO-8859-1
|
0x00 = ISO-8859-1
|
||||||
0x01 = 7 bit ASCII
|
0x01 = 7 bit ASCII
|
||||||
0x80 = Kanji (japanese)
|
0x80 = Kanji (japanese)
|
||||||
0x81 = Korean
|
|
||||||
0x82 = Mandarin (chinese)
|
|
||||||
0xff = libcdio source states: "everything else"
|
|
||||||
1 : Number of first track
|
1 : Number of first track
|
||||||
2 : Number of last track
|
2 : Number of last track
|
||||||
3 : libcdio source states: "cd-text information copyright byte"
|
3 : libcdio source states: "cd-text information copyright byte"
|
||||||
@ -548,6 +588,7 @@ The payload bytes of three 0x8f packs form a 36 byte record.
|
|||||||
I.e. the first byte in this field of 16 counts packs of type 0x80.
|
I.e. the first byte in this field of 16 counts packs of type 0x80.
|
||||||
20 - 27 : Highest sequence byte number of blocks 0 to 7.
|
20 - 27 : Highest sequence byte number of blocks 0 to 7.
|
||||||
28 - 36 : Language code for blocks 0 to 7 (tech3264.pdf appendix 3)
|
28 - 36 : Language code for blocks 0 to 7 (tech3264.pdf appendix 3)
|
||||||
|
Not all of these Codes have ever been seen with CD-TEXT, though.
|
||||||
0x00 = Unknown
|
0x00 = Unknown
|
||||||
0x01 = Albanian
|
0x01 = Albanian
|
||||||
0x02 = Breton
|
0x02 = Breton
|
||||||
@ -650,7 +691,6 @@ The payload bytes of three 0x8f packs form a 36 byte record.
|
|||||||
0x7d = Armenian
|
0x7d = Armenian
|
||||||
0x7e = Arabic
|
0x7e = Arabic
|
||||||
0x7f = Amharic
|
0x7f = Amharic
|
||||||
|
|
||||||
E.g. these three packs
|
E.g. these three packs
|
||||||
42 : 8f 00 2a 00 01 01 03 00 06 05 04 05 07 06 01 02 48 65
|
42 : 8f 00 2a 00 01 01 03 00 06 05 04 05 07 06 01 02 48 65
|
||||||
43 : 8f 01 2b 00 00 00 00 00 00 00 06 03 2c 00 00 00 c0 20
|
43 : 8f 01 2b 00 00 00 00 00 00 00 06 03 2c 00 00 00 c0 20
|
||||||
|
Loading…
Reference in New Issue
Block a user