Yes, this is exactly what I am trying to do, resulting in difficulty getting edits to vote on. I am figuring out the system a bit better now though.
2 Likes
Here is a strange case I wanted to share.
RE: Release “(I Am) OldSchool” by DJ Brokdorff - MusicBrainz
First, if all can have a look at the release and how it was added, I would appreciate it.
Second, there are two audio files, an MP3 and a WAV. These 2 files contain the same recording, yet somehow, they have different AcoustIDs. This is confusing to me. Even worse, since it is the same recording, I cannot differentiate between which AcoustID goes to which file, the WAV or the MP3.
I was told that the quality of a digital release file should not change the AcoustID, but I believe this proves that wrong, or that I misunderstood. I can see that these two files are acoustically different, but I cannot hear that difference.
I wanted to post this as this might be a cause of issues as it relates to digital releases. In prior threads, MB has stated as a group that there is no differentiation on the recording level for different file types (both container and encoder), however, this may end up negating the purpose of the AcoustID. I am unsure, but this sure puts it in question.
EDIT: To clarify, I speak generally that I cannot hear the difference. If one listens close enough, it can be heard, but in terms of how MB does recordings, they are not distinguishable. I hope that makes sense. It is basically a different mastering.
1 Like
For something like this I would fire up Audacity and throw the two tracks in to visually compare.
If you look at the AcoustID fingerprint compare option they are so very very close I would have merged these if I had seen this with two recordings.
https://acoustid.org/fingerprint/89447221/compare/89447222
Maybe that MP3 is compressing enough to just trigger the slightly different mathematical result from AcoustID. Are you seeing two different results in your copy of Picard? You can load and Scan the tracks in Picard without changing the data, just read the AcoustID values.
1 Like
I am unsure what you mean here. I load both recordings into Picard, and do a generate AcoustIDs / fingerprints. It generates them as different, no saving of data done.
I have them as the same recording, but different “tracks” as they are in the release as 2 different files.
Haha - sorry. I am talking before brain has had coffee. 
Same recordings already. Whoops.
I would add this info to the annotation.
1 Like
My issue is that… they are the same recording. That is what confuses me. I am happy to do what anyone suggests though. It is strange that the MP3 was generated from the WAV, yet the AcoustID differs them.
Might I offer… I can share these files with you in totality, via private message/link if you are willing to have a look.
Haha - sorry. I am talking before brain has had coffee. Same recordings already. Whoops.
I would add this info to the annotation. Those fingerprints in the AcoustID compare show these really are so very similar, just the maths of AcoustId is being triggered over a threshold and popping up a new value
I see this as problematic… if MB does not consider the digital file type as different, the AcoustID becomes useless… in a sense.
I can visually see the different in the files, a compressed file is obviously going to be different from the uncompressed version. But if the AcoustID sees them as different, does the AcoustID really tell me if I have the same recording, or does it tell me if I have the same mastering?
I get confused here because MB guideline tells me these recordings are the same, and I would agree, the recording is the same. However, the mastering is different, which MB does not recognize, but it causes the MB recording to have conflicting AcoustIDs.
UHHHH…
If I have a WAV file, that is a recording for sure. Now, if I make this into an MP3, that is a mastering process. No different than making it to M4A or any other format that is not 100% lossless. It is clear here that the AcoustID tells me that the recordings are “different”.
EDIT: Although I can show proof that the proper M4A with CoreAudio is less likely to show as different.
They may be conflicting values, but close enough in the AcoustID fingerprint compare tool that they would have been merged under any other condition.
I see this a lot with bootlegs of concerts from radio. We know it is the same original source, but you then get copies appear from original master tapes, direct from FM to FLAC, from MW to cassette to MP3, ands other messy transfers. The AcoustID values may be different, but the compare shows they are close enough to the same value. And an ear can confirm.
Where that compare really shows up useful is one of those above copies that has gone onto a tape at a different speed. Using the AcoustID fingerprint compare in those cases you can shift the offset down the sample and see it matching up out of sync.
In these cases we know it is all from that same Radio broadcast, so we merge the recordings due to knowing the background. Even though different recording medium has created multiple AcoustIDs.
In your example here you know they are from the same source, and MB therefor treats them as the same. I would be adding notes to the annotation about any mastering you know about, and at least pointing out the separate AcoustIDs.
1 Like
Without going into great depth, here is a quick view:
WAV
MP3
While not the best possible, that is a quality MP3.
1 Like
You are talking to the wrong person on this one as I agree with your puzzle. I understand the mastering issue and the differences this creates. I also know the damage an MP3 compression causes.
MusicBrainz has many terms it uses that are different to how the dictionary defines them. “Recording” has its own specially defined meaning. And this meaning does not take mastering or audio formats into account. It treats an MP3 @ 64kbps taken from a cassette tape of a MW radio broadcast the same as a high bitrate WAV taken straight from the mixing desk that was used for the show.
We keep these separately labelled in our collections, but this is not detail that MB has a category for.
It is only when something is cut out or inserted will MB want to recategorise.
1 Like
I understand. This is just putting me in a spot where MB cannot support the release properly. Either I make 2 recordings that are duplicates, or I use one recording that AcoustID shows to be different. Either way, this is an issue.
If you look at the WAV, there is no interference as you often see … in horizontal anomalies. The MP3 is also nice, although it has the old school soft cutoff at 16kHz. I would not expect this to make a difference though, as for most, this is casual listening transparent.
For AcoustID to be of use, these need to be different recordings. This also might explain to me why so many recordings have 10, 20 30+ AcoustIDs… if each source produces a different AcoustID, only the same pressing of a CD or the same digital file will match. I know I am pumped on coffee now, but this tosses a wrench in the entire concept.
As I am going to refill my coffee… I think that this current strategy in MB is theoretical, not realistic. We can see here that there is a clear contradiction.
We all categorise music in different ways. There is no one single “right” way. It is as I was trying to show above. MusicBrainz looks at the source recording, and not all the spin offs that follow. This is why I like the concert bootleg example. Sometimes people try and clean up that old cassette tape edition they have before sticking it out on yet another bootleg, but it is still the same old source recording in MB’s eyes.
Now the guy who splices together two different concerts, he has made something new. But someone mastering levels and removing crackles is not noted in MB language.
The way you and I want to differentiate our collections is not how the MB database wants to operate. But we can still work within this system.
There are some much weirder people out there. Have you see those people who rock up in the forum asking about automatic de-duplication tools? They want to run automated software over their collections to “remove all the duplicates”. I can’t think of a more horrific concept. But to them they don’t care about mastering. They don’t care about albums. They just want a heap of music to dive in to.
We all use our music different. 
You can still document that the release was as a MP3 and WAV, but this mainly ends up in annotations. It is beyond the level of detail that MusicBrainz works to.
I commented on some votes on recording merges. Others voted yes, but there is no proof that the difference between clean a d explicit has been properly researched. When I do recording merges, if it is not clear from the release which is which, I do not merge, even if ISRC is the same, as editors often confuse them as well. There are numerous examples of recordings having BOTH the clean and explicit ISRC assigned to it.
Drives me nuts that CDs can be differentiated by a sticker but digital releases are “all the same”… except if the barcode is different, LOL!
EDIT: I am going to do some tests… converting the WAV in question here to different formats and different qualities.
Yeah, that is a common problem. Not helped by the CDs not saying what it is. Gets a bigger headache with a popular track on dozens of junk VA collections as no one listens to all of them. They should be separate Recordings but no one has all the examples to check.
I saw a good solution to that kind of mess with a Bjork track. It had two variations due to a sample that was removed due to copyright clearance issues. With that Recording it was split into three versions - with sample, without sample and Unknown. This was done with Disambiguation comments and annotations. Everything initially piled into Unknown. Then as more research was done they could be better split.
This example was extra messy due to that old pre-NGS DiscID mess as many of the Release had the wrong discIDs applied causing even the track length to be distrusted. It also had an utter mess of AcoustIDs crossed over. Probably a dozen or more.
The CDs may be visually different causing a new version, but all the Recordings are merged as the same. (And a sticker would not cause a difference - it would have to be some change on the actual booklet, but I know what you mean)
Remember, with physical products you are buying two things. A package with a disc\tape\LP in it and the recordings. With digital media you are only buying the recording.
My money is on Six different formats, four different AcoustIDs. Also shift from something converted back again. i.e. wav → M4A → MP3 → FLAC and see what kinda mess comes out the end.
2 Likes
Yes, I added the 4 files it came with there. I think it is great that the AcoustID can differentiate, because they are different.
In your edit notes as well, you comments on the audible differences in the different formats. To that, I totally agree. There are many factors that have impact on this, and while many editors tried discrediting my statement, this can even cause an audible difference between a 16 and 24 bit FLAC. While it is a different topic, it only shows that many do not really understand what is happening. It is my opinion that this is the root cause of some of these issues, ignoring real musical differences and distinguishing non musical differences.
I guess there is more to think on. It makes no sense to add a release with two recordings that MB shows being both the same but different. In my opinion, that just takes a release in hand that makes sense, I look it up and I leave confused as I am provided conflicting information, when in reality, there is no conflict.
It still makes sense in the way this MB library is defined. The Release holds two Tracks which are different, and that is documented in the annotation. The fact they share a Recording is just due to the way MB defines a recording.
MB is not telling you that you have to change how you store your music. All it is asking is to share some of your details with the MB database. This database has a narrower definition on what is a “Recording” which makes sense for the majority of uses. And yes, this is based in a history of coming from Physical Media so looks more at the packaging that the music file. It is more of what is recorded and less as to how it is encoded.
To me and my concert bootleg collection it makes much more sense for them all to be linked to the same source Recording. They are the same recording. It is the same music I listen to by ear. I use different means to grade the quality of them. In the same way I have a different scale to grade the quality of my vinyl. Quality of audio playback is outside of the MB database.
4 Likes
I respect your opinion, and the opinion of others. As you stated prior, many people use the data in many different ways. However, I see this differently.
If I have an AcoustID, this is a tool to help me differentiate recordings. In MB uses this tool and bypasses in part its abilities, then MB is at fault. The tool is there, it is just not being used to its fullest capability.
Why does this matter? Well, if I have a recording that MB has with the AcoustID of different edits, remixes, clean vs explicit… and as seen now different file formats of the same source… what is the purpose? If I rip a CD into FLAC, MP3, M4A and Opus, I have a choice to make. Are they the same, or are they different? In this case, the AcoustID follows the different side, while MB follows the same. These are mismatched tools. If I want to recognize a recording, I find it better in my testing (although only a few days in) that MB cannot compare to other platforms in accuracy.
It is my opinion that if MB wants to consider all masters of a recording the same (and not introduce a second layer of differentiation), then it should not be using other tools that do. It creates a mess that people that want accurate info find problematic. It is not doing what it states that it does.
What do you think it is purporting to do?
AcoustID functions exactly as I would expect it to.
As Musicbrainz recordings are defined they can (and often, are likely to) have various releases that sound different/have a different waveform.
I would expect these to generate different ID’s, which we can then point to the same MB recordings.
This all seems very tidy to me 
2 Likes