DJ promo releases

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. :crazy_face: 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.


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:





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. :slight_smile:

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.


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.


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 :thinking:


I believe the intent is to catalog music releases. I believe the use to me helping users identify releases and recordings.

Yes, I would agree, the AcoustID performs quite well. It is not the ID itself where I See the problem.

Thinking through this more, I think the issue I am having is more a result of the bad data vs the use of the current features. While I agree that some recordings (now) can have numerous IDs, there are far too many where an acoustID matches numerous variations of a recording… but that is the result of bad input.

I am finding this issue as I look at these promo releases. They often contain a large amount of remixes of the same recording, and sometimes a lossless and lossy copy of the recordings.

The AcoustID, for me, performs perfectly. It can tell even the difference between a WAV and MP3 of the same recording. I did not know this prior I must admit. Learning this gave me two opposite feelings. One was great, it able to pick up on even differences that one may not be able to hear. The other was not great, since MB takes this accuracy and discards it. That is further amplified with bad data, but that is not part of the topic.

If you look at the scenario, if I have such a release, cataloging it into MB provides no benefit. Meaning that my directory listing is more clear than the result in MB. When I look at the directory, I might see this:

  • some-recording.wav
  • some-recording.mp3
  • some-recording.opus

I can visually see here that although the name of the recording is the same, I have 3 very different versions. If I look in MB at this same release, I would see this:

  • some-recording
  • some-recording
  • some-recording

From here I would need to look at other areas to see if I can figure out what is what, and why it looks weird (as it would to many as the same recording is there multiple times. I then also see that each of them has 3 AcoustIDs, where the reality is that each has only 1.

In this case outlined above, it is not the AcoustID that is problematic, it is MB and the structure. As noted prior, it brings into light that MB does not consider mastering, at times. I have seen releases get new recordings from CDs because you can “hear the difference”… which is generally attributed to mastering, likely some sort of remastering of old recordings. While I agree with that, it is an anomaly of sorts as the same is not applied to a digital release.

A digital release does not have the same identifiers as a CD. If I have a CD, there is a lot to look at, we all know the visual attributes in play. With a digital release a lot of that is just not there. So with “release in hand”, my options are far more limited. The AcoustID is a great tool as it is capable of getting in most cases exact results. I believe it would be fairly accurate (if the database supported it) to even take a file and match it to a specific release, like that was this MP3 version or that was this iTunes version, etc. That would help elevate the digital releases closer to CDs, where I can see two releases differentiated only by a single line in a booklet stating made in A vs B.

This is relevant to the topic as these DJ promos are no longer CD driven, although CDs are still available for some. When I take a CD, I can derive easily that this is track 1, this is 2, etc. So when I look it up in MB, track 1 = track 1. So even if all look the same, I can still match the recordings. On a digital release, say one with no track numbers, this is not possible. I have a folder of files and a MB listing that I may not be able to match file to recording. I would however, if the recordings were not all the same in MB. Not just with AcoustID, but with additional detail.

It is worth noting that you can not rely on AcoustID to be different between WAVE and MP3 or any other encoding, because it is specifically meant to produce the same AcoustID for lossy audio as well. Otherwise it wouldn’t work for what it is supposed to do. If every separate encoding of files ripped from a CD would identify as something completely different nobody would be able to identify their songs. Of course this is all just mathematics about similarity of fingerprints, and there is always that point where the audio is just different enough for the AcoustID server to consider them separate.

But in general the definition of saying that the MP3 encoding of a WAVE is the same recording makes a lot of sense to me. Otherwise for every CD there would need to be an endless number of recordings of all possible ways you can encode this audio. For streaming services this often is even totally fluid as the audio encoding and parameters will be chosen based on the playback device.


I thought this as well, but if you look above, this is proven untrue. If it is specifically meant to “produce the same AcoustID for lossy audio”, it does not do this. The release noted in that portion is proof of this.

Honestly, I like how AcoustID is working, now that I am testing it myself. It is quite nice, and I actually would like a tool to generate this ID, in GUI, locally, to generate these myself. I know there is a tool, a fingerprint GUI, but it only generates them to submit, not save local. I might need to create this myself.

I mean not to argue, I am simply discussing what I am finding in the process of trying to add these releases. What I have discovered is not at all what I was expecting and understood to be true.

I am still trying to think and wrap my head around all this, so any input is welcome. Just because I am generating results does not mean that these results are “scientific”. I am trying now to determine what exactly causes the fingerprinting process to see a WAV different from MP3. The files in the initial post are both DJ supplied, WAV used to make MP3. The MP3 is of reasonable quality, only using the soft 16kHz filter. If it used the hard filter, I would be more confident as to why the difference. I know that @IvanDobsky commented above that in his looking, the two fingerprints looked nearly identical, only small variation. If I recall correctly, the artist who produced this release uses Serato, so quality of product should be there.

Again, I mean no disrespect here. I am simply doing what I said I was going to do, try to add some of these releases. Given that, I can only share what I see in the process.

I will be using the following parameters for MP3 creation from WAV, using LAME encoder, next:

-m j -V 4 -q 3 -lowpass 20.5

That should produce good sample for testing.