Follow

tfw musicbrainz registers the mp3 transcode you did of the flac rip you also did as being exactly the same as the mp3 release that the label released

@djsundog (Former employee of the former company Attributor speaking...) They don't look for binary equivalence; they look for fingerprints in a filtered representation of the audio.

@vertigo I knew they were fingerprinting the audio but didn't realize they were filtering it, huh!

@djsundog Yeah, it's an attempt to circumvent obvious things like speeding up the track, slowing it down, reducing the quality or introducing excess noise, etc. Fingerprinters are pretty intelligent about stuff these days.

@djsundog Really? Considering all of the encoders out there that's surprising.

@djsundog the acoustid tech that musicbrainz uses for matching was explicitly designed to be agnostic to lossy encoding tech, since the point was that it should be able to match lossy encodes of cd rips back to the original cd.

@djsundog a recommended read: "How does Chromaprint work", a doc about the fingerprinting technology used by the acoustid database: oxygene.sk/2011/01/how-does-ch

@kepstin but that's the thing - the flac rip it matched back to the cd, the mp3 transcode it matched back to a digital download release with an altogether different id

@djsundog oh, that's actually pretty strange. Any chance you have the acoustid ids so i could look them up? (musicbrainz picard stores them in the "Acoustid Id" tag)

@djsundog note also that it's possible that both tracks resolved to the same acoustid (matching fingerprints) but picard wasn't able to guess which release of the many releases containing that recording you wanted (possibly because the file didn't have enough metadata tags for picard to do a closer match).

@kepstin not in this case, these are fully tagged already (I was skipping re-importing them) and came back with 100% matches.

@djsundog

musicbrainz.org/recording/a9f2 is the recording indicated, and you'll note that this same recording is on both releases you linked.

So that means that beets was able to figure out the recording and release name, but didn't find enough info in the file to identify the specific release.

@kepstin the tagging on the two sets of mp3s is identical. I'm not sure what you're saying at this point.

@djsundog i'd have to see what the complete set of tags on both files looked like before the beets import to make any further judgment. but it sounds like beets got to the point when matching where it said "well, it could be any one of these releases", and applied some heuristics to guess which one you wanted. And the heuristics just ended up picking different releases for some reason.

@kepstin the same program wrote the same tags to the files at the same time in an automated fashion; there is no difference in tags between the two sets of mp3s. it doesn't matter, I only mentioned it as a curiosity, I don't need a solution.

@djsundog right then - i guess it was just an amusing accident of chance affecting something in the heuristics the beets matcher.

At least it figured out the same *recording* in both cases musicbrainz.org/recording/a9f2 even if it didn't manage to get the same release :)

@djsundog if the files were "fully tagged" already, does that mean they had musicbrainz ids in the file already? if musicbrainz ids were present, beets would just be loading the release from the tagged id without doing any other matching.

@kepstin beets has never re-tagged the mp3 transcodes - they were generated by foobar2000 on the machine that ripped the discs. I just confirmed with ffprobe that there is no fingerprint in any of the meta tags on the mp3s.

fixed width output inside 

Sign in to participate in the conversation
reclaim.technology

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!