Discussion:
grip/cdparanoia/freedb disagree on track length
Jamie Zawinski
2003-01-24 02:24:52 UTC
Permalink
I have a CD where cdparanoia and Grip / FreeDB disagree on the length
of the last audio track. Grip and cdparanoia think the track is of
length 7:06, but the FreeDB data seems to say the track is 9:38.

The CD in question is "Phi in the Sky" by Kidneythieves.
It has 6 tracks, and tracks 1-5 are fine / consistent.

The FreeDB data says that track 6 is supposed to be of length 9:38.
When Grip generates a cddb file itself, it also says 9:38 (that is,
Grip generates cddb files consistent with the one that is currently
on the FreeDB servers.)

The Grip display, and "cdparanoia -vsQ", say that track 6 is of length
7:06. That's also the length of the file I get when I rip it, with
either grip or cdparanoia.

Grip and FreeDB think that there is a 7th track, a data track.
The grip display shows:

01 5:01
02 6:26
03 3:52
04 8:57
05 5:15
06 7:06
07 0:06 (data track, presumably?)

That adds up to 36:43, or 2203 seconds.

cdparanoia -vsQ is in agreement, except that it doesn't list track 7.
It has this to say:

Table of contents (audio tracks only):
track length begin copy pre ch
===========================================================
1. 22635 [05:01.60] 0 [00:00.00] no no 2
2. 28902 [06:25.27] 22635 [05:01.60] no no 2
3. 17393 [03:51.68] 51537 [11:27.12] no no 2
4. 40317 [08:57.42] 68930 [15:19.05] no no 2
5. 23625 [05:15.00] 109247 [24:16.47] no no 2
6. 31968 [07:06.18] 132872 [29:31.47] no no 2
TOTAL 164840 [36:37.65] (audio only)

Note that the total length is off by 6 seconds. I think that this
is because the unshown data track is 6 seconds long (see below.)

The freedb data is here: http://www.freedb.org/freedb/rock/5a093307
Converted to seconds, the numbers in that file come out to:

01 5:02
02 6:25
03 3:52
04 8:58
05 5:15
06 9:38

That adds up to 39:10, or 2350 seconds. This implies that
the data track is 0:06 long (since the cddb file says the
total file length is 2357.)

My standalone CD player (Nakamichi MB-10) is also in agreement: it
says there are 6 tracks (not 7!), total length 36:38 (2198) with
track 6 being 7:06 long.

So how am I ending up with CDDB / FreeDB figures that claim that
track 6 is 9:38 instead of 7:06?

Might the TOC have overlapping tracks, or something? Is this some
new sleazy way of hiding data tracks from audio CD players?

The reason I'm concerned about this is that I have a script that
issue warnings when my MP3 files are not the length that the CDDB
files say they should be, so that I can tell when I've somehow
mis-ripped something. That script is warning about this track,
and so I either need to know how to rip the track properly, or
how to interpret the numbers in the CDDB file to realize that
the track *was* ripped properly. Because right now, the CDDB file
is claiming that the file is two and a half minutes too short.

Any suggestions appreciated...

Versions:

cdparanoia-alpha9.8-11
grip-3.0.1-4
Red Hat Linux release 8.0 (Psyche)
Linux 2.4.18-14 #1 Wed Sep 4 12:13:11 EDT 2002 i686
athlon i386 GNU/Linux
--
Jamie Zawinski
***@jwz.org http://www.jwz.org/
***@dnalounge.com http://www.dnalounge.com/
Andy Key
2003-01-24 08:13:22 UTC
Permalink
Hi Jamie,

I'd guess that the CD was burned as multisession, with the data track being
in the second session. CDDA only allows for one session, so most standalone
players will only read the first session, and hence only show the audio
tracks. I don't currently have *nix installed anywhere so I can't verify
how Grip and cdparanoia handle data tracks on multisession CDs. If you
happen to have a windows machine available, I can send you a bit of code
that can read the TOC using the subchannel, which will show exactly what the
problem with the CD is.

In any case, the numbers do appear strange, and it probably has something to
do with the multisession toc.

rgds,
Andy Key
Post by Jamie Zawinski
I have a CD where cdparanoia and Grip / FreeDB disagree on the length
of the last audio track. Grip and cdparanoia think the track is of
length 7:06, but the FreeDB data seems to say the track is 9:38.
The CD in question is "Phi in the Sky" by Kidneythieves.
It has 6 tracks, and tracks 1-5 are fine / consistent.
The FreeDB data says that track 6 is supposed to be of length 9:38.
When Grip generates a cddb file itself, it also says 9:38 (that is,
Grip generates cddb files consistent with the one that is currently
on the FreeDB servers.)
The Grip display, and "cdparanoia -vsQ", say that track 6 is of length
7:06. That's also the length of the file I get when I rip it, with
either grip or cdparanoia.
Grip and FreeDB think that there is a 7th track, a data track.
01 5:01
02 6:26
03 3:52
04 8:57
05 5:15
06 7:06
07 0:06 (data track, presumably?)
That adds up to 36:43, or 2203 seconds.
cdparanoia -vsQ is in agreement, except that it doesn't list track 7.
track length begin copy pre ch
===========================================================
1. 22635 [05:01.60] 0 [00:00.00] no no 2
2. 28902 [06:25.27] 22635 [05:01.60] no no 2
3. 17393 [03:51.68] 51537 [11:27.12] no no 2
4. 40317 [08:57.42] 68930 [15:19.05] no no 2
5. 23625 [05:15.00] 109247 [24:16.47] no no 2
6. 31968 [07:06.18] 132872 [29:31.47] no no 2
TOTAL 164840 [36:37.65] (audio only)
Note that the total length is off by 6 seconds. I think that this
is because the unshown data track is 6 seconds long (see below.)
The freedb data is here: http://www.freedb.org/freedb/rock/5a093307
01 5:02
02 6:25
03 3:52
04 8:58
05 5:15
06 9:38
That adds up to 39:10, or 2350 seconds. This implies that
the data track is 0:06 long (since the cddb file says the
total file length is 2357.)
My standalone CD player (Nakamichi MB-10) is also in agreement: it
says there are 6 tracks (not 7!), total length 36:38 (2198) with
track 6 being 7:06 long.
So how am I ending up with CDDB / FreeDB figures that claim that
track 6 is 9:38 instead of 7:06?
Might the TOC have overlapping tracks, or something? Is this some
new sleazy way of hiding data tracks from audio CD players?
The reason I'm concerned about this is that I have a script that
issue warnings when my MP3 files are not the length that the CDDB
files say they should be, so that I can tell when I've somehow
mis-ripped something. That script is warning about this track,
and so I either need to know how to rip the track properly, or
how to interpret the numbers in the CDDB file to realize that
the track *was* ripped properly. Because right now, the CDDB file
is claiming that the file is two and a half minutes too short.
Any suggestions appreciated...
cdparanoia-alpha9.8-11
grip-3.0.1-4
Red Hat Linux release 8.0 (Psyche)
Linux 2.4.18-14 #1 Wed Sep 4 12:13:11 EDT 2002 i686
athlon i386 GNU/Linux
--
Jamie Zawinski
_______________________________________________
fdb-dev mailing list
http://dtype.org/mailman/listinfo/fdb-dev
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Jamie Zawinski
2003-01-24 09:00:53 UTC
Permalink
Post by Andy Key
I don't currently have *nix installed anywhere so I can't verify
how Grip and cdparanoia handle data tracks on multisession CDs. If you
happen to have a windows machine available, I can send you a bit of code
that can read the TOC using the subchannel, which will show exactly what the
problem with the CD is.
In any case, the numbers do appear strange, and it probably has something to
do with the multisession toc.
I do not. But if you can point me at any code I can compile/run on
Linux that might provide more info, I'd be happy to point it at the
disc...

Is there some easy way to answer the question, "is this a multi-session
disc?"
--
Jamie Zawinski
***@jwz.org http://www.jwz.org/
***@dnalounge.com http://www.dnalounge.com/
Mike Oliphant
2003-01-24 16:35:34 UTC
Permalink
The issue is with discs that have data tracks. There is gap between the
end of the last track and the actual beginning of the data track. Grip
and cdparanoia account for this, but freedb does not. Grip sends freedb
what it expects, but displays the actual play time.

Mike
Post by Jamie Zawinski
I have a CD where cdparanoia and Grip / FreeDB disagree on the length
of the last audio track. Grip and cdparanoia think the track is of
length 7:06, but the FreeDB data seems to say the track is 9:38.
The CD in question is "Phi in the Sky" by Kidneythieves.
It has 6 tracks, and tracks 1-5 are fine / consistent.
The FreeDB data says that track 6 is supposed to be of length 9:38.
When Grip generates a cddb file itself, it also says 9:38 (that is,
Grip generates cddb files consistent with the one that is currently
on the FreeDB servers.)
The Grip display, and "cdparanoia -vsQ", say that track 6 is of length
7:06. That's also the length of the file I get when I rip it, with
either grip or cdparanoia.
Grip and FreeDB think that there is a 7th track, a data track.
01 5:01
02 6:26
03 3:52
04 8:57
05 5:15
06 7:06
07 0:06 (data track, presumably?)
That adds up to 36:43, or 2203 seconds.
cdparanoia -vsQ is in agreement, except that it doesn't list track 7.
track length begin copy pre ch
===========================================================
1. 22635 [05:01.60] 0 [00:00.00] no no 2
2. 28902 [06:25.27] 22635 [05:01.60] no no 2
3. 17393 [03:51.68] 51537 [11:27.12] no no 2
4. 40317 [08:57.42] 68930 [15:19.05] no no 2
5. 23625 [05:15.00] 109247 [24:16.47] no no 2
6. 31968 [07:06.18] 132872 [29:31.47] no no 2
TOTAL 164840 [36:37.65] (audio only)
Note that the total length is off by 6 seconds. I think that this
is because the unshown data track is 6 seconds long (see below.)
The freedb data is here: http://www.freedb.org/freedb/rock/5a093307
01 5:02
02 6:25
03 3:52
04 8:58
05 5:15
06 9:38
That adds up to 39:10, or 2350 seconds. This implies that
the data track is 0:06 long (since the cddb file says the
total file length is 2357.)
My standalone CD player (Nakamichi MB-10) is also in agreement: it
says there are 6 tracks (not 7!), total length 36:38 (2198) with
track 6 being 7:06 long.
So how am I ending up with CDDB / FreeDB figures that claim that
track 6 is 9:38 instead of 7:06?
Might the TOC have overlapping tracks, or something? Is this some
new sleazy way of hiding data tracks from audio CD players?
The reason I'm concerned about this is that I have a script that
issue warnings when my MP3 files are not the length that the CDDB
files say they should be, so that I can tell when I've somehow
mis-ripped something. That script is warning about this track,
and so I either need to know how to rip the track properly, or
how to interpret the numbers in the CDDB file to realize that
the track *was* ripped properly. Because right now, the CDDB file
is claiming that the file is two and a half minutes too short.
Any suggestions appreciated...
cdparanoia-alpha9.8-11
grip-3.0.1-4
Red Hat Linux release 8.0 (Psyche)
Linux 2.4.18-14 #1 Wed Sep 4 12:13:11 EDT 2002 i686
athlon i386 GNU/Linux
--- >8 ----
List archives: http://www.xiph.org/archives/
Paranoia homepage: http://www.xiph.org/paranoia/
To unsubscribe from this list, send mail to 'paranoia-dev-***@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Loading...