Disc IDs from ripped files or CUE sheets (not from physical CDs)

Hi,

I always assumed that one should only add a disc ID calculated from a physical CD. Recently I was made aware that some people are adding disc IDs derived from CUE sheets or ripped files.

From cursory reading of Disc ID Calculation - MusicBrainz it seems to me that calculating disc ID from anything else than an actual CD is unlikely to produce a result which exactly matches that particular CD. Is my understanding correct?

I would like to perform some experiments with my own CDs to verify this, but I don’t know any Linux tools that can calculate disc ID from ripped files. Does anyone know such programs?

1 Like

I think if you have the right log file from EAC/XLD you’re good to go?
Here’s a tool:
http://eac-log-lookup.blogspot.com/

I doubt you can get anything useful in terms of discID if it’s just the ripped music tracks.

6 Likes

If you are experimenting, then with the EAC Log Lookup it is all about the Table of Contents on the CD. This is not something that can be generated from the loose files, it has to be extracted from the CD.

With an EAC log the important lines are these:

TOC of the extracted CD

 Track |   Start  |  Length  | Start sector | End sector 
---------------------------------------------------------
    1  |  0:00.32 |  4:00.40 |        32    |    18071   
    2  |  4:00.72 |  3:32.73 |     18072    |    34044   
    3  |  7:33.70 |  7:06.37 |     34045    |    66031   
    4  | 14:40.32 |  4:44.03 |     66032    |    87334   
    5  | 19:24.35 |  6:32.00 |     87335    |   116734   
    6  | 25:56.35 |  7:40.60 |    116735    |   151294   
    7  | 33:37.20 |  3:25.45 |    151295    |   166714   
    8  | 37:02.65 |  3:50.40 |    166715    |   184004   
    9  | 40:53.30 |  2:04.22 |    184005    |   193326   

The above text is enough to paste in to the EAC-Log Lookup and get the correct result.

I don’t know a Linux tool that can pull the same info from a CD. There are plenty of Linux users around who no doubt will soon turn up with a tool of some form.

6 Likes

I already knew which CD you had chosen by looking at the track lengths :nerd_face:

5 Likes

:rofl: @kellnerd - And for bonus points, which year of re-issue of the disk?

No doubt you’re like me and have a few variations of this one… :crazy_face:

3 Likes

You can theoretically calculate discids from ripped tracks - you just have to verify the length is measurable in sectors (1/75th of second). Given you know the sample rate is 44100 (CD redbook standard) and you divide this by 75, you get 588. Now if you take the length of the track in samples and it’s divisible by 588 with no remainder, it’s very likely it was sourced from CD rip. If you repeat for this for all tracks in an album then you could calculate A discid. But that doesn’t mean it’s valid…

The problem is that you have is no PREGAP info. In my limited experience, more CDs have no special PREGAP info than actually do but this is meaningless because you have no way of knowing without comparing against the actual CD and that’s why discids should NEVER be submitted from ripped tracks.

However, for verification/lookups against already submitted discids, then it’s perfectly harmless…

9 Likes

The discid tool that is part of libdiscid can, and I think most distros include a package for it.

If .NET Core is installed (possibly requiring Alpine, Ubuntu or Debian; not sure about other distros), then you can do dotnet tool install -g MetaBrainz.MusicBrainz.dotnet-mbdiscid to install my .NET based version, after which it can be run via dotnet mbdiscid.

3 Likes

Hi folks, until recently I also used the XLD app to create disc IDs.

I took a CD and ribbed it with XLD, so I made a single Flac file out of it and the .log File and .cue File created. Then I created a .log file again using the .cue and the single Flac file.

Firts logfile:
X Lossless Decoder version 20191004 (152.0)

XLD extraction logfile from 2020-05-05 13:34:31 +0200

Stereo MC’s / Connected

Used drive : HL-DT-ST DVDRAM GP08NU11 (revision JV01)
Media type : Pressed CD

Ripper mode : XLD Secure Ripper
Disable audio cache : OK for the drive with a cache less than 1375KiB
Make use of C2 pointers : YES
Read offset correction : 667
Max retry count : 20
Gap status : Analyzed, Appended

TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 05:14:00 | 32 | 23581
2 | 05:14:32 | 04:13:50 | 23582 | 42606
3 | 09:28:07 | 03:47:38 | 42607 | 59669
4 | 13:15:45 | 05:44:50 | 59670 | 85519
5 | 19:00:20 | 04:26:00 | 85520 | 105469
6 | 23:26:20 | 04:09:62 | 105470 | 124206
7 | 27:36:07 | 05:01:38 | 124207 | 146819
8 | 32:37:45 | 04:20:62 | 146820 | 166381
9 | 36:58:32 | 03:50:63 | 166382 | 183694
10 | 40:49:20 | 03:50:12 | 183695 | 200956
11 | 44:39:32 | 05:04:50 | 200957 | 223806
12 | 49:44:07 | 03:49:63 | 223807 | 241044

List of alternate offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 3 | -664 | 44

AccurateRip Summary (DiscID: 001878d2-00e31606-ac0c8d0c)
Track 01 : OK (v1+v2, confidence 233/277)
Track 02 : OK (v1+v2, confidence 231/270)
Track 03 : OK (v1+v2, confidence 232/272)
Track 04 : OK (v1+v2, confidence 232/271)
Track 05 : OK (v1+v2, confidence 233/274)
Track 06 : OK (v1+v2, confidence 234/275)
Track 07 : OK (v1+v2, confidence 232/273)
Track 08 : OK (v1+v2, confidence 232/274)
Track 09 : OK (v1+v2, confidence 231/272)
Track 10 : OK (v1+v2, confidence 230/271)
Track 11 : OK (v1+v2, confidence 231/273)
Track 12 : OK (v1+v2, confidence 229/268)
->All tracks accurately ripped.

Second logfile:
X Lossless Decoder version 20191004 (152.0)

XLD AccurateRip checking logfile

TOC of the selected file
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 05:14:00 | 32 | 23581
2 | 05:14:32 | 04:13:50 | 23582 | 42606
3 | 09:28:07 | 03:47:38 | 42607 | 59669
4 | 13:15:45 | 05:44:50 | 59670 | 85519
5 | 19:00:20 | 04:26:00 | 85520 | 105469
6 | 23:26:20 | 04:09:62 | 105470 | 124206
7 | 27:36:07 | 05:01:38 | 124207 | 146819
8 | 32:37:45 | 04:20:62 | 146820 | 166381
9 | 36:58:32 | 03:50:63 | 166382 | 183694
10 | 40:49:20 | 03:50:12 | 183695 | 200956
11 | 44:39:32 | 05:04:50 | 200957 | 223806
12 | 49:44:07 | 03:49:63 | 223807 | 241044

List of alternate offset correction values
(1) -664 (confidence 44)

AccurateRip Summary (DiscID: 001878d2-00e31606-ac0c8d0c)
Track 01 : OK (v1+v2, confidence 233/277)
Track 02 : OK (v1+v2, confidence 231/270)
Track 03 : OK (v1+v2, confidence 232/272)
Track 04 : OK (v1+v2, confidence 232/271)
Track 05 : OK (v1+v2, confidence 233/274)
Track 06 : OK (v1+v2, confidence 234/275)
Track 07 : OK (v1+v2, confidence 232/273)
Track 08 : OK (v1+v2, confidence 232/274)
Track 09 : OK (v1+v2, confidence 231/272)
Track 10 : OK (v1+v2, confidence 230/271)
Track 11 : OK (v1+v2, confidence 231/273)
Track 12 : OK (v1+v2, confidence 229/268)
->All tracks accurately ripped.

As well as I this see the result is the same or not?

I hope I can help. Unfortunately, my English only comes from the translater, Gruss Dani

1 Like

OK, now I have created a log file only of the individual flac’s without .cue

XLD AccurateRip checking logfile

TOC of the selected file
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:00 | 05:14:00 | 0 | 23549
2 | 05:14:00 | 04:13:50 | 23550 | 42574
3 | 09:27:50 | 03:47:38 | 42575 | 59637
4 | 13:15:13 | 05:44:50 | 59638 | 85487
5 | 18:59:63 | 04:26:00 | 85488 | 105437
6 | 23:25:63 | 04:09:62 | 105438 | 124174
7 | 27:35:50 | 05:01:38 | 124175 | 146787
8 | 32:37:13 | 04:20:62 | 146788 | 166349
9 | 36:58:00 | 03:50:63 | 166350 | 183662
10 | 40:48:63 | 03:50:12 | 183663 | 200924
11 | 44:39:00 | 05:04:50 | 200925 | 223774
12 | 49:43:50 | 03:49:63 | 223775 | 241012

AccurateRip Summary (DiscID: 00187732-00e30aa7-af0c8d0c)
Track 01 : NG (total 4 submissions)
Track 02 : NG (total 4 submissions)
Track 03 : NG (total 4 submissions)
Track 04 : NG (total 4 submissions)
Track 05 : NG (total 4 submissions)
Track 06 : NG (total 4 submissions)
Track 07 : NG (total 4 submissions)
Track 08 : NG (total 4 submissions)
Track 09 : NG (total 4 submissions)
Track 10 : NG (total 4 submissions)
Track 11 : NG (total 3 submissions)
Track 12 : NG (total 3 submissions)
->0 track accurately ripped, 12 tracks not
the ID is always the same … But the duration is no longer the same because the breaks are missing
Oops, the disc ID is no longer the same, but is that the ID we’re talking about?

1 Like

Nope, the DiscID on MB is kGu6_VUlbOch3jRKq7sDLAA2abU-. You get there by pasting your log into the previously linked tool. Your third “DiscID” is different because the offset information for track 1 is missing (00:00:00 instead of 00:00:32).

If you want, we can also discuss this in German.

2 Likes

Cool, das macht es einfacher fĂĽr mich.
Ich dachte ich könnte bei diesem Problem hier weiterhelfen, deshalb habe ich auch die Versuche mit XLD, der CD, den .cues’s und den FLAC’s gemacht. Ich habe den Link https://eac-log-lookup.blogspot.com/ ausprobiert, verstehe aber nicht ganz in wieweit mir das bei unserem Problem weiterhelfen soll. Ich sehe dann nur mein XLD-Logfile in Textform.

Viele meiner Musik stammt aus, sagen wir mal aus dunklen Kanälen. Irgendwann einmal bin ich dann auf MusicBrainz und Picard gestossen, später kam dann noch die App “Yate” dazu. Und habe so eine Möglichkeit gefunden meine digitale Musiksammlung korrekt zu taggen und gleichzeitig mein etwas schlechtes Gewissen zu beruhigen in dem ich der Allgemeinheit etwas zurückgebe indem ich auf MusicBrainz neue Veröffentlichungen erstelle, bestehende vervollständige, Artwork hochlade usw.

Aber eigentlich möchte ich nur wissen ob ich mit flac’s, ape’s usw. eine Disc-ID erstellen darf oder nicht. Vielfach ist bei diesen Files auch ein cue oder ein Logfile aus dem original Rip der CD dabei oder ich könnte mithilfe von XLD oder Yate eines erstellen.

Wenn ich aber beim Problem mit den cue’s, flac’s etc. weiterhelfen kann lass es mich bitte wissen und ich kann noch weitere Versuche machen.

Wenn man dort ein gültiges XLD- oder EAC-Logfile (oder nur den Teil mit der TOC) einfügt, sollten unter dem Eingabefeld mehrere Links eingeblendet werden. Hier musst du einfach den Link Musicbrainz disc ID anklicken, um in der MusicBrainz-Suche für die richtige Veröffentlichung zu landen. Genau die selbe Seite wird auch aufgerufen, wenn man die TOC einer physischen CD nachschlägt.

Falls du ein Logfile inklusive der extrahierten TOC zur Verfügung hast, von dem du genau weißt, zu welcher Veröffentlichung/CD es gehört, kannst du die daraus berechnete DiscID mit dieser Veröffentlichung verknüpfen. Nur anhand eines Cuesheets und verlustfreien Audiodateien kann man eine TOC (und somit die DiscID) nicht immer eindeutig bestimmen, da hier der Offset von Track 1 verloren gegangen ist.
Dieser ist in den meisten Fällen 0 bzw. eigentlich 150 (je nach Zählweise), aber es gibt eben auch Ausnahmen, wie man an dem von dir gegebenen Beispiel erkennen kann: Ohne den Offset von 32 Sektoren (Logfile 1 & 2) erhält man eine andere DiscID (für Logfile 3), die in MB nicht vorhanden ist.

Damit du die DiscID auch mit der richtigen Veröffentlichung innerhalb einer Veröffentlichungsgruppe verknüpfen kannst, solltest du dieses Verfahren am Besten nur für Rips verwenden, die neben einem Logfile auch gescanntes Artwork oder andere Hinweise auf die exakte Version enthalten. Ausnahmen sind natürlich seltenere Alben oder Sondereditionen, bei denen man davon ausgehen kann, dass es von ihnen nur die eine Version gibt.

Ich hoffe, ich konnte dir damit weiterhelfen.

2 Likes

Konntest Du, Danke. Ich muss das alles nochmal genau durchgehen.
Kannst du mir auch noch sagen was .accurip fĂĽr eine Datei ist, entsteht sie wenn eine CD gerippt wird und ist sie ein Hinweis auf Korrektheit der Daten?

Just going to reiterate that I really really do not like this “let’s submit a disc id based on a log file with no guarantee it represents a physical disc correctly”.

Disc IDs are expected to be sources of truth, so if there is an app/site that allows breaking that expectation, that makes me very uncomfortable.

5 Likes

Most distros include also icedax:

icedax -D /dev/sr0 -JHg -v toc,sectors,trackid
Type: ROM, Vendor 'HL-DT-ST' Model 'DVDRAM GH22NS70 ' Revision 'EX00' MMC+CDDA
569344 bytes buffer memory requested, 4 buffers, 55 sectors
#icedax version 1.1.11, real time sched., soundcard, libparanoia support
Tracks:10 42:57.50
CDINDEX discid: aO6WQWramsZ_Di8DzG9qg8TPw3s-
CDDB discid: 0x760a110a
CD-Text: detected
CD-Extra: not detected
Album title: 'The Dark Side Of The Moon' from 'Pink Floyd'
T01:       0  1:07.13
T02:    5038  2:49.40
T03:   17753  3:45.29
T04:   34657  6:53.29
T05:   65661  4:44.05
T06:   86966  6:23.15
T07:  115706  7:49.17
T08:  150898  3:26.32
T09:  166380  3:46.50
T10:  183380  2:12.45
Leadout:  193325
T:  1 ISRC:    GBN9Y1100076
T:  2 ISRC:    GBN9Y1100077
T:  3 ISRC:    GBN9Y1100078
T:  4 ISRC:    GBN9Y1100079
T:  5 ISRC:    GBN9Y1100080
T:  6 ISRC:    GBN9Y1100081
T:  7 ISRC:    GBN9Y1100082
T:  8 ISRC:    GBN9Y1100083
T:  9 ISRC:    GBN9Y1100140
T: 10 ISRC:    GBN9Y1100084
2 Likes

There is your key data https://musicbrainz.org/cdtoc/aO6WQWramsZ_Di8DzG9qg8TPw3s-

If icedax is a standard tool, can’t see why the data can’t be submitted. Certainly seems to resolve accurately - assuming you have a 2011\2016 CD in your hands?

We should check if current version of icedax has either these bugs:

  • Enhanced CD last audio track duration 2:30 delta
  • SACD huge track times
1 Like

Would also be good to see how it handles pregap data too. Basically all those non-standard CDs.

The Icedax documentation I found is dated 26 Sep 2006, before the fix for the “last audio track before data track (Enhanced CD) 2:30 duration delta” issue.
Before the SACD huge track lengths issue too.

Also it mentions www.musicbrainz.org and CDINDEX.
We no longer use www. and CDINDEX sounds like an old terminology?
I never heard of it but CD Index is mentioned in Disc ID Calculation.

So I never tested Icedax but maybe we should not encourage disc ID submissions from its logs.

Would it make sense to have some .iso files of various “special” TOCs, with silence as audio content? Those could then be used to test utilities (I’d certainly welcome the ability to test my own implementation against such cases).