[Top][All Lists]

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

Re: [Libcdio-devel] Fedora bug report concerning CD-TEXT

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Fedora bug report concerning CD-TEXT
Date: Tue, 29 Mar 2016 17:58:53 +0200


i send a copy of this comment to address@hidden
because i believe to see a bug.

James Olin Oden wrote in

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

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, 

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");
             i_buf = 0;
+            pack.i_track++;
           if (pack.db_chars)


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


reply via email to

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