Hi, i send a copy of this comment to [email protected] because i believe to see a bug.
James Olin Oden wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1321677#c3 > CD-TEXT data from CD Lead-in: Looks ok. The overall title is "Deeper Dance", the first track title is the same, then come "The Hunt" and "Harold's dream". ----------------------------------------------------------------- CD-TEXT Song Title: I am trying to grasp the reader code in libcdio-0.93.tar.bz2 ./lib/driver/cdtext.c : cdtext_data_init() line 628 ff. The bug could be in the fact that the title "The Hunt" fits completely into pack 2, but this pack is still announced to start by a part of track 1: > 0 : 80 00 00 00 D e e p e r D a n c e 23 93 > 1 : 80 00 01 0c 00 D e e p e r D a n c 51 0b > 2 : 80 01 02 0b e 00 T h e H u n t 00 H 88 92 > 3 : 80 03 03 01 a r o l d ' s D r e a cb be Each line is a CD-Text Pack. The current track numbers are announced by the second byte of each pack. Here: 00, 00, 01, 03. Fifth to 17th byte are text payload. The last two are checksums. See also: https://www.gnu.org/software/libcdio/cd-text-format.html The payload 00 in pack 1 terminates the overall CD Title (track #0). The 'D' begins title #1 which extends to pack 2, which therefore announces track number 01. "The Hunt" should go to track #2, but this code snippet records the completed payload text under track number pack.i_track: case CDTEXT_PACK_TITLE: cdtext_set(p_cdtext, CDTEXT_FIELD_TITLE, buffer, pack.i_track, charset); The variable pack.i_track stems from call cdtext_read_pack(&pack, p_data); where it was copied from p_data[1], the second byte of the pack. So it is 1 with both calls, the one for track #1 "Deeper Dance" and the one for track #2 "The Hunt". "The Hunt" overwrites "Deeper Dance" in track #1 while track #2 does not get to see any title, because the next pack (3) already continues the title for track #3. ----------------------------------------------------------------- Fix proposal: (Not even compiled yet. I need to break out an old cheat sheet.) ----------------------------------------------------------------- Increment track counter after a CD-TEXT buffer was recorded. This is necessary for the case that the same text pack contains a complete further text. --- ./lib/driver/cdtext.c.orig 2014-09-24 22:53:52.000000000 +0200 +++ ./lib/driver/cdtext.c 2016-03-29 17:23:40.184363311 +0200 @@ -688,8 +688,9 @@ cdtext_data_init(cdtext_t *p_cdtext, uin cdtext_set(p_cdtext, CDTEXT_FIELD_ISRC, buffer, pack.i_track, "ISO-8859-1"); break; } i_buf = 0; + pack.i_track++; } if (pack.db_chars) j+=2; ----------------------------------------------------------------- ISRC: There are no packs of type 0x8e which would store Media Catalog Number of the CD and the ISRCs of the tracks. I follow in libcdio-0.93 the calls which get the ISRC cdio_get_track_isrc , p_cdio->op.get_track_isrc , get_track_isrc_linux, mmc_get_track_isrc , SCSI command CDIO_MMC_GPCMD_READ_SUBCHANNEL = 0x42 Command 42h appears in MMC-1 to 4, but was removed in MMC-5. It fetches info from the tracks, not from the CD-TEXT in Lead-in. Regrettably i have no means to put info there when burning CD-RW. One would have to put debugging printfs into ./lib/driver/mmc/mmc.c : mmc_get_track_isrc_private() to see how the content of buf evolves. Especially one should memset(buf, 0, 28) rather than relying on char buf[28] = { 0, }; for the case that ./lib/driver/gnu_linux.c : run_mmc_cmd_linux() fails silently. It uses ioctl(CDROM_SEND_PACKET) which gives less error indication than ioctl(SG_IO). Can you try a different CD drive with libcdio ? Just to be sure that it is not a drive firmware problem. > DDP files generated from DSP Quattro. So the exact CD production process is out of my reach anyway. Even if i knew how to squeeze ISRC into the tiny holes between the sound bits of a track. Have a nice day :) Thomas
