Bug 1321677 - libcdio/cd-info is not reading cd-text correctly
Summary: libcdio/cd-info is not reading cd-text correctly
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: libcdio
Version: 23
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Adrian Reber
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-28 21:02 UTC by James Olin Oden
Modified: 2016-12-20 19:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 19:41:00 UTC


Attachments (Terms of Use)

Description James Olin Oden 2016-03-28 21:02:07 UTC
User-Agent:       Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build Identifier: 

I was testing out a new mastered CD on my linux box running Fedora 23.  When I looked at it with rhythm box it showed that the first song had the name of the 2nd song, and the 2nd song had no name.  The remaining 8 songs were correct. 

I then decided to check things at a lower level and so I ran cd-info which comes with the libcdio package.   It showed the same thing, and it also showed a corruption in the ISRC information which is in the sub channels.   In this case it showed that ISRC value of the 8th track was duplicated on the 9th track, and the 10th track had the ISRC value for the 9th track.   When I run the CD through my car stereo it sees the names all correctly (but of course I can't look at the ISRC info on my car stereo).   I can also see the correct information for the track names on my Mac OS X box (I think its running mavericks).   

My conclusion is that there is some sort of bug corrupting memory in libcdio with regard to reading cd-text, but I haven't dug into the API myself to really understand it.  I don't know how to re-create this without the full CD image.   I can put this up on drop box perhaps, if you like.  Let me know.

Here is the example output:

==== BEGIN OUTPUT ====
[joden@joden Documents]$ cd-info
cd-info version 0.93 x86_64-redhat-linux-gnu
Copyright (c) 2003-2005, 2007-2008, 2011-2013 R. Bernstein
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
CD location   : /dev/cdrom
CD driver name: GNU/Linux
   access mode: IOCTL

Vendor                      : HL-DT-ST
Model                       : DVDRAM GUB0N   
Revision                    : LV20
Hardware                                  : CD-ROM or DVD
Can eject                                 : Yes
Can close tray                            : Yes
Can disable manual eject                  : Yes
Can select juke-box disc                  : No

Can set drive speed                       : No
Can read multiple sessions (e.g. PhotoCD) : Yes
Can hard reset device                     : Yes

Reading....
  Can read Mode 2 Form 1                  : Yes
  Can read Mode 2 Form 2                  : Yes
  Can read (S)VCD (i.e. Mode 2 Form 1/2)  : Yes
  Can read C2 Errors                      : Yes
  Can read IRSC                           : Yes
  Can read Media Channel Number (or UPC)  : Yes
  Can play audio                          : Yes
  Can read CD-DA                          : Yes
  Can read CD-R                           : Yes
  Can read CD-RW                          : Yes
  Can read DVD-ROM                        : Yes

Writing....
  Can write CD-RW                         : Yes
  Can write DVD-R                         : Yes
  Can write DVD-RAM                       : Yes
  Can write DVD-RW                        : No
  Can write DVD+RW                        : No
__________________________________

Disc mode is listed as: CD-DA
CD-ROM Track List (1 - 10)
  #: MSF       LSN    Type   Green? Copy? Channels Premphasis?
  1: 00:02:00  000000 audio  false  no    2        no
  2: 04:04:38  018188 audio  false  no    2        no
  3: 09:08:00  040950 audio  false  no    2        no
  4: 13:50:57  062157 audio  false  no    2        no
  5: 17:49:57  080082 audio  false  no    2        no
  6: 23:29:38  105563 audio  false  no    2        no
  7: 30:36:19  137569 audio  false  no    2        no
  8: 35:22:38  159038 audio  false  no    2        no
  9: 40:13:66  180891 audio  false  no    2        no
 10: 46:35:01  209476 audio  false  no    2        no
170: 56:24:48  253698 leadout (569 MB raw, 569 MB formatted)
Media Catalog Number (MCN): 0000000000000
TRACK  1 ISRC: QMWT21600001
TRACK  2 ISRC: QMWT21600002
TRACK  3 ISRC: QMWT21600003
TRACK  4 ISRC: QMWT21600004
TRACK  5 ISRC: QMWT21600005
TRACK  6 ISRC: QMWT21600006
TRACK  7 ISRC: QMWT21600007
TRACK  8 ISRC: QMWT21600008
TRACK  9 ISRC: QMWT21600008
TRACK 10 ISRC: QMWT21600009
Last CD Session LSN: 0
audio status: no status
volume level port 0: 255 (0..255) 100 (0..100)
volume level port 1: 255 (0..255) 100 (0..100)
volume level port 2:   0 (0..255)   0 (0..100)
volume level port 3:   0 (0..255)   0 (0..100)
__________________________________
CD Analysis Report

Language 0 'English':
CD-TEXT for Disc:
    TITLE: Deeper Dance
    PERFORMER: James Olin Oden
CD-TEXT for Track  1:
    TITLE: The Hunt
    PERFORMER: James Olin Oden
CD-TEXT for Track  2:
    PERFORMER: James Olin Oden
CD-TEXT for Track  3:
    TITLE: Harold's Dream
    PERFORMER: James Olin Oden
CD-TEXT for Track  4:
    TITLE: Jazz Fusion No. 9
    PERFORMER: James Olin Oden
CD-TEXT for Track  5:
    TITLE: Love's Tattoo
    PERFORMER: James Olin Oden
CD-TEXT for Track  6:
    TITLE: The Day I Told Her Micheal Domhnaill Died
    PERFORMER: James Olin Oden
CD-TEXT for Track  7:
    TITLE: The Fool Amongst the Keeners
    PERFORMER: James Olin Oden
CD-TEXT for Track  8:
    TITLE: Love Is Not Tame
    PERFORMER: James Olin Oden
CD-TEXT for Track  9:
    TITLE: Dear John and the Big Red Pickup Truck
    PERFORMER: James Olin Oden
CD-TEXT for Track 10:
    TITLE: Dance Right Out of My Grave
    PERFORMER: James Olin Oden
==== END OUTPUT ====


Reproducible: Always

Comment 1 Adrian Reber 2016-03-29 08:40:04 UTC
Thanks for the detailed report. I tried to reproduce it with a CD I have, which is not easy as most CDs do not seem to use CD-TEXT. The one I found looks correct. Every track has the correct TITLE. I will reach out to the upstream developers to see if the can comment on the problems you are seeing.

Comment 2 Thomas Schmitt 2016-03-29 09:19:35 UTC
Hi,

it would be interesting to see the output and the binary file

  ./cdtext.dat

which gets produced by this command

  cdrskin -vvv dev=/dev/cdrom -toc

After some lengthy info about program, drive, and medium, there
will appear lines like

  CD-TEXT data from CD Lead-in:
     0 : 80 00 00 00  J  o  y  f  u  l     N  i  g  h  t f0 f7
     ...
    45 : 8f 02 2d 00 00 00 00 00 09 00 00 00 00 00 00 00 6a 24

The lines which begin by " : 80" contain track title texts.
The first title text belongs to the overall CD. The
subsequent 0-terminated texts belong to the tracks.

By what program did you burn the CD ?


Have a nice day :)

Thomas

Comment 3 James Olin Oden 2016-03-29 12:57:59 UTC
Hi Thomas,

I have two CD's that I have found exhibit the behavior of having the cd-text somewhat mismatched (the other was also one of my albums).   I tried some random CD's laying around my house and they all looked good.   Both of the CD's that have the problem had their DDP files generated from DSP Quattro.   That's the software my engineer uses.   

Here is the dump from cdrskin:

CD-TEXT data from CD Lead-in:
   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
   4 : 80 03 04 0d  m 00  J  a  z  z     F  u  s  i  o 1d 87
   5 : 80 04 05 0a  n     N  o  .     9 00  L  o  v  e ad 1e
   6 : 80 05 06 04  '  s     T  a  t  t  o  o 00  T  h d2 71
   7 : 80 06 07 02  e     D  a  y     I     T  o  l  d c7 77
   8 : 80 06 08 0e     H  e  r     M  i  c  h  e  a  l b7 5e
   9 : 80 06 09 0f     D  o  m  h  n  a  i  l  l     D ff 9b
  10 : 80 06 0a 0f  i  e  d 00  T  h  e     F  o  o  l 6f d2
  11 : 80 07 0b 08     A  m  o  n  g  s  t     t  h  e 98 e7
  12 : 80 07 0c 0f     K  e  e  n  e  r  s 00  L  o  v 27 1f
  13 : 80 08 0d 03  e     I  s     N  o  t     T  a  m 1e b6
  14 : 80 08 0e 0f  e 00  D  e  a  r     J  o  h  n    e3 84
  15 : 80 09 0f 0a  a  n  d     t  h  e     B  i  g    93 f2
  16 : 80 09 10 0f  R  e  d     P  i  c  k  u  p     T be d1
  17 : 80 09 11 0f  r  u  c  k 00  D  a  n  c  e     R aa 51
  18 : 80 0a 12 07  i  g  h  t     O  u  t     o  f    86 e2
  19 : 80 0a 13 0f  M  y     G  r  a  v  e 00 00 00 00 0f 50
  20 : 81 00 14 00  J  a  m  e  s     O  l  i  n     O 60 b0
  21 : 81 00 15 0c  d  e  n 00  J  a  m  e  s     O  l 12 a8
  22 : 81 01 16 08  i  n     O  d  e  n 00  J  a  m  e a3 3e
  23 : 81 02 17 04  s     O  l  i  n     O  d  e  n 00 3c c3
  24 : 81 03 18 00  J  a  m  e  s     O  l  i  n     O 95 5b
  25 : 81 03 19 0c  d  e  n 00  J  a  m  e  s     O  l e7 43
  26 : 81 04 1a 08  i  n     O  d  e  n 00  J  a  m  e 80 be
  27 : 81 05 1b 04  s     O  l  i  n     O  d  e  n 00 52 9a
  28 : 81 06 1c 00  J  a  m  e  s     O  l  i  n     O 5d b0
  29 : 81 06 1d 0c  d  e  n 00  J  a  m  e  s     O  l 2f a8
  30 : 81 07 1e 08  i  n     O  d  e  n 00  J  a  m  e 9e 3e
  31 : 81 08 1f 04  s     O  l  i  n     O  d  e  n 00 bd 34
  32 : 81 09 20 00  J  a  m  e  s     O  l  i  n     O 4f 94
  33 : 81 09 21 0c  d  e  n 00  J  a  m  e  s     O  l 3d 8c
  34 : 81 0a 22 08  i  n     O  d  e  n 00 00 00 00 00 2a da
  35 : 8f 00 23 00 00 01 0a 00 14 0f 00 00 00 00 00 00 6a 40
  36 : 8f 01 24 00 00 00 00 00 00 00 00 03 25 00 00 00 25 db
  37 : 8f 02 25 00 00 00 00 00 09 00 00 00 00 00 00 00 81 4f

And here is the "od -cv" output of the cdtext.dat:

0000000 002 256  \0  \0 200  \0  \0  \0   D   e   e   p   e   r       D
0000020   a   n   c   e   # 223 200  \0 001  \f  \0   D   e   e   p   e
0000040   r       D   a   n   c   Q  \v 200 001 002  \v   e  \0   T   h
0000060   e       H   u   n   t  \0   H 210 222 200 003 003 001   a   r
0000100   o   l   d   '   s       D   r   e   a 313 276 200 003 004  \r
0000120   m  \0   J   a   z   z       F   u   s   i   o 035 207 200 004
0000140 005  \n   n       N   o   .       9  \0   L   o   v   e 255 036
0000160 200 005 006 004   '   s       T   a   t   t   o   o  \0   T   h
0000200 322   q 200 006  \a 002   e       D   a   y       I       T   o
0000220   l   d 307   w 200 006  \b 016       H   e   r       M   i   c
0000240   h   e   a   l 267   ^ 200 006  \t 017       D   o   m   h   n
0000260   a   i   l   l       D 377 233 200 006  \n 017   i   e   d  \0
0000300   T   h   e       F   o   o   l   o 322 200  \a  \v  \b       A
0000320   m   o   n   g   s   t       t   h   e 230 347 200  \a  \f 017
0000340       K   e   e   n   e   r   s  \0   L   o   v   ' 037 200  \b
0000360  \r 003   e       I   s       N   o   t       T   a   m 036 266
0000400 200  \b 016 017   e  \0   D   e   a   r       J   o   h   n    
0000420 343 204 200  \t 017  \n   a   n   d       t   h   e       B   i
0000440   g     223 362 200  \t 020 017   R   e   d       P   i   c   k
0000460   u   p       T 276 321 200  \t 021 017   r   u   c   k  \0   D
0000500   a   n   c   e       R 252   Q 200  \n 022  \a   i   g   h   t
0000520       O   u   t       o   f     206 342 200  \n 023 017   M   y
0000540       G   r   a   v   e  \0  \0  \0  \0 017   P 201  \0 024  \0
0000560   J   a   m   e   s       O   l   i   n       O   ` 260 201  \0
0000600 025  \f   d   e   n  \0   J   a   m   e   s       O   l 022 250
0000620 201 001 026  \b   i   n       O   d   e   n  \0   J   a   m   e
0000640 243   > 201 002 027 004   s       O   l   i   n       O   d   e
0000660   n  \0   < 303 201 003 030  \0   J   a   m   e   s       O   l
0000700   i   n       O 225   [ 201 003 031  \f   d   e   n  \0   J   a
0000720   m   e   s       O   l 347   C 201 004 032  \b   i   n       O
0000740   d   e   n  \0   J   a   m   e 200 276 201 005 033 004   s    
0000760   O   l   i   n       O   d   e   n  \0   R 232 201 006 034  \0
0001000   J   a   m   e   s       O   l   i   n       O   ] 260 201 006
0001020 035  \f   d   e   n  \0   J   a   m   e   s       O   l   / 250
0001040 201  \a 036  \b   i   n       O   d   e   n  \0   J   a   m   e
0001060 236   > 201  \b 037 004   s       O   l   i   n       O   d   e
0001100   n  \0 275   4 201  \t      \0   J   a   m   e   s       O   l
0001120   i   n       O   O 224 201  \t   !  \f   d   e   n  \0   J   a
0001140   m   e   s       O   l   = 214 201  \n   "  \b   i   n       O
0001160   d   e   n  \0  \0  \0  \0  \0   * 332 217  \0   #  \0  \0 001
0001200  \n  \0 024 017  \0  \0  \0  \0  \0  \0   j   @ 217 001   $  \0
0001220  \0  \0  \0  \0  \0  \0  \0 003   %  \0  \0  \0   % 333 217 002
0001240   %  \0  \0  \0  \0  \0  \t  \0  \0  \0  \0  \0  \0  \0 201   O

Comment 4 Thomas Schmitt 2016-03-29 15:51:52 UTC
Hi,

i send a copy of this comment to libcdio-devel@gnu.org
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

Comment 5 Thomas Schmitt 2016-03-29 16:49:00 UTC
Hi,

my change proposal compiles. (The cheat sheet was only for Git version.
The instructions in libcdio-0.93/README.libcdio worked fine for me.)

I created a (white noise) audio CD-RW with these text packs

   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
   4 : 80 03 04 0d  m 00 00 00 00 00 00 00 00 00 00 00 04 73
   ...

With my change i get from cd-info:

CD-TEXT for Track  1:
        TITLE: Deeper Dance
        ...
CD-TEXT for Track  2:
        TITLE: The Hunt
        ...
CD-TEXT for Track  3:
        TITLE: Harold's Dream
        ...

Without my change i get what James gets:

CD-TEXT for Track  1:
        TITLE: The Hunt
        ...
CD-TEXT for Track  2:
        ...
CD-TEXT for Track  3:
        TITLE: Harold's Dream
        ...


Have a nice day :)

Thomas

Comment 6 Thomas Schmitt 2016-03-29 17:35:09 UTC
Hi,

Leon Merten Lohse on libcdio-devel@gnu.org took over for upstream.
  http://lists.gnu.org/archive/html/libcdio-devel/2016-03/msg00004.html

He asks for a binary copy of  ./cdtext.dat  as extracted from the CD.


Have a nice day :)

Thomas

Comment 7 James Olin Oden 2016-03-29 17:43:18 UTC
Just sent it to Leon directly (didn't figure they wanted an attachment sent to the mailing list).

Comment 8 James Olin Oden 2016-03-29 23:51:47 UTC
So connected my USB cdrom to my linux laptop, placed the CD in it, and ran cd-info.    It exhibited the same behavior save that instead of duplicating the 8 ISRC on the 9th, it duplicated the 7th on the 8th:

Media Catalog Number (MCN): 
TRACK  1 ISRC: QMWT21600001
TRACK  2 ISRC: QMWT21600002
TRACK  3 ISRC: QMWT21600003
TRACK  4 ISRC: QMWT21600004
TRACK  5 ISRC: QMWT21600005
TRACK  6 ISRC: QMWT21600006
TRACK  7 ISRC: QMWT21600007
TRACK  8 ISRC: QMWT21600007
TRACK  9 ISRC: QMWT21600008
TRACK 10 ISRC: QMWT21600009
Last CD Session LSN: 0
audio status: no status
volume level port 0: 216 (0..255)  84 (0..100)
volume level port 1: 216 (0..255)  84 (0..100)
volume level port 2:   0 (0..255)   0 (0..100)
volume level port 3:   0 (0..255)   0 (0..100)
__________________________________
CD Analysis Report

Language 0 'English':
CD-TEXT for Disc:
	TITLE: Deeper Dance
	PERFORMER: James Olin Oden
CD-TEXT for Track  1:
	TITLE: The Hunt
	PERFORMER: James Olin Oden
CD-TEXT for Track  2:
	PERFORMER: James Olin Oden
CD-TEXT for Track  3:
	TITLE: Harold's Dream
	PERFORMER: James Olin Oden
CD-TEXT for Track  4:
	TITLE: Jazz Fusion No. 9
	PERFORMER: James Olin Oden
CD-TEXT for Track  5:
	TITLE: Love's Tattoo
	PERFORMER: James Olin Oden
CD-TEXT for Track  6:
	TITLE: The Day I Told Her Mícheál Domhnaill Died
	PERFORMER: James Olin Oden
CD-TEXT for Track  7:
	TITLE: The Fool Amongst the Keeners
	PERFORMER: James Olin Oden
CD-TEXT for Track  8:
	TITLE: Love Is Not Tame
	PERFORMER: James Olin Oden
CD-TEXT for Track  9:
	TITLE: Dear John and the Big Red Pickup Truck
	PERFORMER: James Olin Oden
CD-TEXT for Track 10:
	TITLE: Dance Right Out of My Grave
	PERFORMER: James Olin Oden

Comment 9 Thomas Schmitt 2016-03-30 06:55:06 UTC
Hi,

the CD-TEXT TITLE problem is not bound to a particular drive
and quite easy to reproduce.

But the ISRC problem seems to be partly drive dependent. Possibly it
is only reproducible by your physical CD medium unless you find a
free software command which i could use here to produce such a CD.
(I currently assume that your ISRC got written by what is described
 in MMC-4 as "4.2.4.5.4 ADR=3 (0011b) – Mode-3 Q".)

If you are willing to make experiments with libcdio, e.g.
  http://ftp.gnu.org/gnu/libcdio/libcdio-0.93.tar.bz2
then i propose you first take care that in
  ./lib/driver/mmc/mmc.c : mmc_get_track_isrc_private()
the buffer gets fully zeroed.

Further you should watch what replies the function gets from
the MMC command.

----------------------------------------------------------------------
--- ./lib/driver/mmc/mmc.c.orig 2014-09-25 03:19:42.000000000 +0200
+++ ./lib/driver/mmc/mmc.c      2016-03-30 08:26:24.268567826 +0200
@@ -559,6 +559,7 @@ mmc_get_track_isrc_private ( void *p_env
 
   CDIO_MMC_SET_COMMAND(cdb.field, CDIO_MMC_GPCMD_READ_SUBCHANNEL);
   CDIO_MMC_SET_READ_LENGTH8(cdb.field, sizeof(buf));
+  memset(buf, 0, sizeof(buf));
 
   cdb.field[1] = 0x0;
   cdb.field[2] = 0x40;
@@ -570,8 +571,18 @@ mmc_get_track_isrc_private ( void *p_env
                              &cdb, SCSI_MMC_DATA_READ,
                              sizeof(buf), buf);
   if(i_status == 0) {
+
+    int i;
+    fprintf(stderr, "libcdio_DEBUG: After CDIO_SUBCHANNEL_TRACK_ISRC:\n");
+    for (i = 9; i < sizeof(buf); i++)
+      fprintf(stderr, " %2.2X", (unsigned char) buf[i]);
+    fprintf(stderr, "\n");
+
     return strdup(&buf[9]);
   }
+
+  fprintf(stderr, "libcdio_DEBUG: CDIO_SUBCHANNEL_TRACK_ISRC failed\n");
+
   return NULL;
 }
 
----------------------------------------------------------------------

Although i did not write ISRC to the subchannels of the tracks but
rather to the CD-TEXT packs, the command 42h READ SUB-CHANNEL delivers
the ISRC from CD-TEXT:

  Vendor                      : HL-DT-ST
  Model                       : DVDRAM GH24NSC0 
  Revision                    : LK00
  ...
  libcdio_DEBUG: After CDIO_SUBCHANNEL_TRACK_ISRC:
   58 59 42 4C 47 31 31 30 31 32 33 34 00 04 00 DB 00 00 00
  TRACK  1 ISRC: XYBLG1101234
  libcdio_DEBUG: After CDIO_SUBCHANNEL_TRACK_ISRC:
   58 59 42 4C 47 31 31 30 30 30 30 35 00 45 00 DB 00 00 00
  TRACK  2 ISRC: XYBLG1100005
  libcdio_DEBUG: After CDIO_SUBCHANNEL_TRACK_ISRC:
   58 59 42 4C 47 31 31 30 30 30 30 36 00 37 00 DB 00 00 00
  TRACK  3 ISRC: XYBLG1100006


Have a nice day :)

Thomas

Comment 10 Thomas Schmitt 2016-03-30 09:41:41 UTC
Hi,

i have to correct myself about the ISRC in the track sub-channels
of my test CD-RW.
libburn underneath cdrskin writes ISRC to the sub-channels.
Either via Mode Page 05 for TAO, or via the CUE SHEET of SAO.

So the ISRC reply of command 42h READ SUB-CHANNEL does not mean
that it would read the ISRC info from CD-TEXT.


Have a nice day :)

Thomas

Comment 11 James Olin Oden 2016-03-30 14:23:29 UTC
Hecdrdao read-toc --device /dev/cdrom ~/x.tocy so used cdrdao to get at the ISRC info like this:

   cdrdao read-toc --device /dev/cdrom ~/x.toc

And this found the correct ISRC information.

Comment 12 James Olin Oden 2016-03-30 14:25:02 UTC
Oh my I don't know what happened with that text, but it was supposed to read:

So I used cdrdao to get at the ISRC info like this:

the rest is correct.

Comment 13 Thomas Schmitt 2016-04-01 09:26:52 UTC
Hi,

after the libcdio CD-TEXT problems seem to be diagnosed and
on the way of being fixed, i now look at cdrdao's source.
(Does cdrdao-1.2.3 compile on Redhat ? On Debian 8 i had to
 comment out a stat(2) call in ./dao/ScsiIf-linux.cc because
 of strange C++ problems.)

First observation: Like libcdio it does not implement text
repetition by single TAB.
Second: A colorful zoo of drivers for unstandardized 1990s
hardware obscures the activities around ISRC reading.

By help of gdb i could catch cdrdao when it issues SCSI command
BEh READ CD with Sub-channel Selection Bits set to 1:
  ./dao/CdrDriver.cc : CdrDriver::analyzeTrackScan()
  ./dao/GenericMMC.cc : GenericMMC::readSubChannels()
This command is used to read all of the track data.

The MMC-4 specs say in table 353 and  6.24.3.2.2:
  "001b | RAW P-W Sub-channel data shall be returned."
  "Raw P-W sub-channel is the 96 bytes of sub-channel returned
   in the order received from the disc surface."
The complete command is
  {0xbe, 0x00, 0x00, 0x00, 0x18, 0xcf, 0x00, 0x00, 0x1a, 0xf8,
   0x01, 0x00}
From the reply it picks the ISRC. (Probably returned by the command
multiple times while it is applied to the whole track.)

So the SCSI commands for obtaining ISRC differ between libcdio
and cdrdao.
The command used by libcdio is deprecated since MMC-5.
The command used by cdrdao is not deprecated but implies reading
a substantial part of the track before the first ISRC appears in
sub-channel data.


It is possible that the command 42h READ SUB-CHANNEL is broken
on contemporary drives and gives libcdio wrong replies.
But before blaming the drive firmware, it might be worth a try to
set in
  libcdio-0.93/lib/driver/mmc/mmc.c
the transfer length to the value 24 that is actually described in
MMC-4 and not to 28, as given by the buffer size.

--- lib/driver/mmc/mmc.c        2016-04-01 11:20:19.949259693 +0200
+++ lib/driver/mmc/mmc.c.orig   2014-09-25 03:19:42.000000000 +0200
@@ -551,7 +551,7 @@ mmc_get_track_isrc_private ( void *p_env
                              )
 {
   mmc_cdb_t cdb = {{0, }};
-  char buf[24] = { 0, };
+  char buf[28] = { 0, };
   int i_status;
 
   if ( ! p_env || ! run_mmc_cmd )

Best would be to apply the two-step approach of first executing
with transfer length 4, learning the Sub-channel Data Length from
bytes 2 and 3 of the reply, and then re-execute with a transfer
length of 4 more than the told value.


(My motivation to implement ISRC reading from sub-channel in
 libburn is now very low. What a swamp.)


Have a nice day :)

Thomas

Comment 14 Thomas Schmitt 2016-04-01 09:31:13 UTC
Hi,

i messed up the diff proposal. Of course it must be:

--- lib/driver/mmc/mmc.c.orig   2014-09-25 03:19:42.000000000 +0200
+++ lib/driver/mmc/mmc.c        2016-04-01 11:20:19.949259693 +0200
@@ -551,7 +551,7 @@ mmc_get_track_isrc_private ( void *p_env
                              )
 {
   mmc_cdb_t cdb = {{0, }};
-  char buf[28] = { 0, };
+  char buf[24] = { 0, };
   int i_status;
 
   if ( ! p_env || ! run_mmc_cmd )


Have a nice day :)

Thomas

Comment 15 Thomas Schmitt 2016-04-02 07:17:36 UTC
Hi,

it turned out that the code about reading ISRC is potentially dangerous
because its strdup()  relies on MMC-4 specs which promise a 0-byte
in byte 17 of the reply of READ SUB-CHANNEL.

Although i would bet CD semantics on that 0-byte, i would not bet
the memory integrity of the program on it.

So the test whether transfer length 24 yields better results
should be done with this change:

--- lib/driver/mmc/mmc.c.orig   2014-09-25 03:19:42.000000000 +0200
+++ lib/driver/mmc/mmc.c        2016-04-02 08:59:01.285553911 +0200
@@ -551,7 +551,7 @@ mmc_get_track_isrc_private ( void *p_env
                              )
 {
   mmc_cdb_t cdb = {{0, }};
-  char buf[28] = { 0, };
+  char buf[25];
   int i_status;
 
   if ( ! p_env || ! run_mmc_cmd )
@@ -559,6 +559,7 @@ mmc_get_track_isrc_private ( void *p_env
 
   CDIO_MMC_SET_COMMAND(cdb.field, CDIO_MMC_GPCMD_READ_SUBCHANNEL);
   CDIO_MMC_SET_READ_LENGTH8(cdb.field, sizeof(buf));
+  memset(buf, 0, sizeof(buf));
 
   cdb.field[1] = 0x0;
   cdb.field[2] = 0x40;
@@ -568,8 +569,9 @@ mmc_get_track_isrc_private ( void *p_env
   i_status = run_mmc_cmd(p_env, mmc_timeout_ms,
                              mmc_get_cmd_len(cdb.field[0]),
                              &cdb, SCSI_MMC_DATA_READ,
-                             sizeof(buf), buf);
+                             24, buf);
   if(i_status == 0) {
+    buf[24] = 0;
     return strdup(&buf[9]);
   }
   return NULL;


This was tested by prepending "valgrind" to the program start in
script ./src/cd-info . Result:

  ==29605== LEAK SUMMARY:
  ==29605==    definitely lost: 40 bytes in 3 blocks
  ...
  ==29605== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The use of constants 24 and 25 might not match the coding style of
libcdio. So this is only a rough test proposal, not a patch for
inclusion in libcdio.


Have a nice day :)

Thomas

Comment 16 Adrian Reber 2016-11-18 13:47:56 UTC
libcdio 0.94 is available in rawhide:

http://koji.fedoraproject.org/koji/buildinfo?buildID=814552

Does 0.94 include the CD-TEXT fixes?

Comment 17 Thomas Schmitt 2016-11-18 14:11:54 UTC
Hi,

i think i see the necessary change for the CD-TEXT Title problem in
  http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=2a95247a574256e268270edbf4588bcea7b26a28
Afterwards happened some branch-or-merge work which i do not understand.

Looking into the release tag tree file:
  http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=blob;f=lib/driver/cdtext.c;h=966b0b19598012aeed9d38803f83f3f66336c95a;hb=13b434adf3a21be656b2a5e5b6b8dba842e99219
i believe to see it in line 752.

So libcdio-0.94 would definitely be worth a try.


Have a nice day :)

Thomas

Comment 18 Fedora End Of Life 2016-11-24 16:16:17 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Fedora End Of Life 2016-12-20 19:41:00 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.