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
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.
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
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
Hi, i send a copy of this comment to libcdio-devel 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
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
Hi, Leon Merten Lohse on libcdio-devel 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
Just sent it to Leon directly (didn't figure they wanted an attachment sent to the mailing list).
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
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
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
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.
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.
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
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
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
libcdio 0.94 is available in rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=814552 Does 0.94 include the CD-TEXT fixes?
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
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.
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.