I have many CDs stored digitally as single FLAC with CUE. I recently added one to MB and would like to add the Disc ID as it is a somewhat rare release, Is there a way to have Picard open the CUE file rather than query the media drive? Basically, to take what I can view in Flacon for example, and use that to submit to MB. I can assume that maybe the reason this feature is not there (or not easy to find) is to help prevent bogus data from bring uploaded, so it requires you to use the media. If that is correct and a hard rule, I fully understand. Just want to upload all the data I can for the release
2 Likes
XLD can do this. But it runs only on macOS.
1 Like
Do you have log files?
2 Likes
That looks like it will work for most of them.
On Linux, the flactag program can generate submission URLs for flacs with embedded cue sheets with the -s switch
3 Likes
Thank you. I will have a look at this. It sounds like it may exactly what I am looking for, especially for those with no logs.
I suppose the issue is that for a plain cue file, there is no guarantee it matches the physical medium (and I’m not sure a cue file uses frames rather than times). A ripper log is better in that regard.
Adding disc ids not based on the physical medium kinda makes them useless.
1 Like
Are you suggesting that I should not submit without having the physical disc present and directly involved in submission? I have not yet submitted any, but have reviewed the tools suggested. If so, that is fine if that is the preference here. For me, I store them as a FLAC RIP and CUE at a min, and can and have also used them to recreate the CDs. But that serves my purposes, so if it is not fit here, I just need to know. I want to help, so entering something that is not valid or undesired is something I would not want to do.
I have a mix of formats, I do not use EAC anymore as I use Linux and besides, it has a history of flaw. Lately I have been using abcde most. (For those not aware, abcde is a real name of a software for ripping). I have personally found that avoiding a GUI has led to a more consistent result. Historically, I have used EAC and a variety of other softwares. So that is what I have and what I do for archival, and not that it matters for this, but I typically then use qaac to create files for portable use when needed. I still have many physical CDs as well, I just do not use them for much of anything anymore. I would estimate that I have approx 70% of my CD sourced archived audio still here with a physical CD to back it.
So… obviously, using the CDs is desired and approved. I will wait on a consensus on using data from archived audio without a backing CD to use. I have explained what I have, so just let me know how it fits in and I will follow.
All I mean is that a disc ID is supposed to ID a physical disc. It’s defined in terms of starting/ending frames (as read from the cd toc).
If a cleanly-ripped flac+cue accurately retains the necessary information, then I’m fine with it being used to generate disc ids for the database.
But that probably won’t be the case for /every/ flac+cue, so I’m wary of software that would allow just any flac/set of flacs/… to be used to seed disc IDs.
Of course, any new CDs you rip from now on, I’d prefer it if you use picard (or alternatives) to do a disc lookup as part of the process.
I completely understand what you are saying. You are correct, at least to me, on what you say that not all rips with CUE match. What data do you want to be present in the file (log, cue or other)? I believe you are looking for the segment like this:
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.32 | 2:50.48 | 32 | 12829
2 | 2:51.05 | 2:36.27 | 12830 | 24556
This segment is not always there, not even in the EAC log files (not always). You might also be able to use segments like this, where it stores a disc ID (well a version of an ID)?
REM DATE 1985
REM DISCID 7908650A
REM COMMENT “ExactAudioCopy v0.99pb5”
I guess it would be safest for me to not use existing rips as my purpose is audio quality, where I will have DR logs, spectrograms, etc. In all honesty, although it is nice to have, the above data is sort of useless in terms of archiving quality audio, so I would need to check case-by-case to see if such data is there, or which ever data is indicated to me to satisfy what MB wants to capture.
Is it possible to have a clear requirement of what is needed (assuming no physical CD) to meet the desired requirements of a disc ID submission? That would be much easier to follow. Currently I know it states EAC log and one other format, but that is not concise as not all EAC logs, for example, contain the same pieces of data. Maybe a post of a sample approved file with the sections highlighted so one can see the data and the format that the data is needed in?
Yes, that segment (or something like it) is what’s needed (the discid listed is probably the freedb id).
A MB disc ID is calculated based on number of tracks, disc size (usually the end sector of the last track), and the starting sector of each track.
1 Like
Makes sense. Thank you for the comprehensive replies. Could I also as if the MB disc ID is unique to MB? In addition, is there any sort of conversion factor to other IDs, such as the FreeDB ID? My intent on asking this is not to be generating IDs from other sorts of data, but to understand the MB disc ID and its relationship to other data, if such a relationship exists. Does the MB disc ID have any use other than within MB? Example might be… is there a decoder for them, so I could go in MB, take a disc ID and decode it to get the information that was used to generate it?
I don’t know if they’re used elsewhere.
They’re made by hashing data, so they’re not reversible (and so cannot be converted to freedb ids either).
https://wiki.musicbrainz.org/Disc_ID_Calculation
The information used to generate the Disc ID is the CD TOC. MB stores the full TOC when you add a Disc ID, so even though you cannot “decode” a Disc ID, you can can go to https://musicbrainz.org/cdtoc/<insert disc id here> to see the corresponding TOC.
Of course, this only works if someone previously added that Disc ID to the MB database.
1 Like
Thank you for this info. I will save this information.
Does this mean that what actually happens is that the TOC is submitted to MB and MB server(s) generate the disc ID, vs the disc ID being generated locally and then submitted to MB? I have not looked into that much, but I thought that there was an algorithm in one or more of the libraries installed local to generate them.
Sorry to be so technical, but I am curious as to the full workings of this ID. For example, is it something like a UPC where it may be generated by one, but is used by many, or maybe like an ASIN where it is specific to a certain entity, but may be referenced by others, etc. I am suspecting it is like the other MB ids that are assigned to releases, artists, etc… just like the Apple IDs are internal Apple identifiers / part numbers… but I can use those numbers to lookup information assuming Apple has kept the number live/active. Even in this case, it is limited because if Apple takes down the ID, there is no history of it vs a UPC which sort of lives forever, if that makes sense.
Yes.
The process for calculating the Disc ID is documented in the page that @Zastai indicated. You may also want to read up on hash functions, if you’re not familiar with them. The important thing to understand is that the Disc ID is calculated deterministically from the TOC, so anyone can do it locally, if they want, and obtain the same Disc ID, as long as they have the same TOC.
MBIDs work differently. They are generated randomly when an entity is created. You cannot calculate the MBID for a release, even if you have the title, artist, tracklist, etc. The only thing you can do is use that information to look up the release on MusicBrainz, i.e. ask MB what MBID was assigned (by MB) to that release.
2 Likes