Acoustid implementation

petitminion

[deleted] A recording can be associated to multiple versions of an audio track with significant differences.

yes. If we want to allow people to choose between differents version of an audio file it will be a new feature that requires some ui design. But I don't see how this is related with releases. If an audio file is linked to a recording, the recoding to a release but the audio file don't match the release it a mb db error. And I don't think fw should handle those

[deleted] If Funkwhale were to make use of this to associate a file to unrelated releases

How we could associate a upload to an unrelated release ? fw upload -> acoustid -> recording -> mb tracks -> releases. I see no issues here.

[deleted] Recordings do not fulfill the purpose you want and would result in numerous database problems sue to unexpected behaviour.

Afaik Acoustid create a relation with recordings : we have no choices. And Again, I don't see the problems here :s

[deleted] Recordings do not point to an exact audio version of a file, rather they point to similar enough ones. Those can be rather significant differences in reality.

If recordings are linked to very differents audios files I see it has a mb problem. Not a funkwhale one. We have to chose either to follow mb db or not. But we can't follow it on some points and on others not.

[deleted]

petitminion If recordings are linked to very differents audios files I see it has a mb problem.

MusicBrainz recordings are not made to point to an exact version of an audio recording. You can't use MusicBrainz's database of recordings to build releases that don't have an uploaded track. It's just not what they're meant for.

You will not improve anything. You will just cause confusion and eventually anyone who uses MusicBrainz to tag their files carefully will ditch Funkwhale completely. I can vouch for this because all my music is tagged accurately using MusicBrainz tags and I know MusicBrainz is not a solution to this problem at all, it's just gonna make my releases irreparably unrecoverable.

phw

I should have chimed into this discussion earlier, but let me now add some info as a Picard developer.

petitminion If an audio file is linked to a recording, the recoding to a release but the audio file don't match the release it a mb db error. And I don't think fw should handle those

On MB there is a difference between a recording ID and a track ID. The recordings do indeed ignore some differences that might be present on the track level. E.g. the same recording with varying silence at the end still is considered the same recording on MB. This e.g. affects the gapless album tracks animaldaydream is referring to: An album might be, for artistic reasons, a continuous, gapless piece of audio, where one track seamlessly goes into the next. But single tracks of that album might e.g. be added to compilations or best-of albums. And there they probably will get added with a short silence at the end to separate them from the next, now unrelated, track.

Likewise mastering differences are ignored, e.g. the CD and Vinyl release, even though mastered for different media, will share the same recordings.

[deleted] I have been made aware that AcoustID fingerprints are actually more sensitive to audio differences than I thought, that they can even pick up differences between a lossless audio file and its transcoded lossy versions.

The fingerprints will be slightly different between the lossless and lossy (or different quality lossy) files. But AcoustID as a whole is designed to ignore exactly these differences. If you have a lossless FLAC and create a lossy MP3 and AAC file from it then all those ideally will end up with the same AcoustID. Otherwise the whole thing would not work for its intended purpose of identifying the recording.

AcoustID is intentionally designed to ignore some differences. Also there is some other in-accuracy that can lead to more different recordings to still identify as the same. AcoustID takes the fingerprint of the first 30 seconds of an recording plus the duration of of the recording for identification. First this means differences after the first 30 seconds are not picked up (this could for example ignore differences between those "clean lyrics" versions and the normal version). And also duration differences up to a certain threshold (I'd need to look this up, but I think it's 20 or 30 seconds) are ignored and still assigned the same AcoustID.

Some general thoughts from my side:

You should not base file duplicates on the concept of MB recordings or AcoustID alone. These can be a strong indication of duplicates, but they do not necessarily mean files taken from different releases are universally interchangeable.
You can use AcoustID to find matching recordings after all this is what AcoustID has been designed to do. As long a there is a sufficient number of submitted fingerprints and there are no mass wrong submissions it is pretty good at that job. But for full identification of recording + release you need to take more information into account (existing metadata and duration is what you'll normally have). This should consider all files belonging to one release as a whole. Then you can link a file to combined recording and release MBID.
Fully automating this will cause errors (as pointed out above by rob and animaldaydreams) and is better accompanied by user interaction. At least there should maybe be a system where uncertain matches get put forward to the user to review and fix, and there should be a system for users to manually correct matching mistakes.
There are also a lot of simple cases where there is no big ambiguity in matches. That's true for a lot of newer digital releases.
I believe automatic matching could be better and there is much potential to improve the existing lookup in e.g. Picard. rob's recent ventures into this (see links in his post above) is pretty interesting, take a look at that. It's solely based on metadata for now, but it looks at all the files and tries to group and match them into MB releases the best way. For long I have been dreaming about a combined lookup in Picard that uses both metadata and AcoustID fingerprints to get the best match (but so far did not find the time to work on this). But in the end I'm convinced some user control is necessary.

petitminion

and thx a lot [deleted] for your incomes they are very helpfull 🙂

petitminion

[deleted]

[deleted] MusicBrainz recordings are not made to point to an exact version of an audio recording.

No but has I said before, I don't see how this is a problem. And this is not related to link a fw track to a mb release, it's related to the fact that a recording can be linked to different audio files.

[deleted] You can't use MusicBrainz's database of recordings to build releases that don't have an uploaded track.

Plz provide technical information because afaik mb tracks are linked to a release and to a recording. So I don't see how it's not possible to link a recording to a release.
What do you mean by "build release that don't have an uploaded track" ?

petitminion

[deleted] eventually anyone who uses MusicBrainz to tag their files carefully will ditch Funkwhale completely. I

This feature will not change the audio file tags and it will not be applied to audio file that have mbids tag so it will not be a problem

[deleted]

petitminion I don't think we should associate a track to a release if the track doesn't have the release MBID on it.

I now have a feeling you think Picard adds a release MBID to every file. When you add a standalone track and don't assign it to a release it will tag the rest of the MBIDs and won't fill in the release and release group.

I thought you wanted Funkwhale to collate tracks with unrelated release MBIDs into a new release just based on their recording MBID.

petitminion

[deleted] ofc we will not create arbitrary association...if a track is a standalone recording we will follow this.

Ok so now that everything is clear here is a resume :

This feature will be opt-in from admins
We will not ask for user review (if a user wants to be sure his track are well tagged he can tag them properly..)
Audio file tags will not be changed
4 Assign a track to its release will be done following mb db.

Questions :

Do we want to support various audio-files per recording ? (perso I don't think this is needed)

Does someone think we miss something ?

[deleted]

petitminion

petitminion Do we want to support various audio-files per recording ? (perso I don't think this is needed)

We do because different masters and continuous albums would be broken otherwise.

Each file should be linked to both a recording MBID, a release MBID, and a tracklist. Not just the recording MBID. Users don't expect a file from a release to be used in another release, so supporting multiple audio files per recording is essential.

petitminion

[deleted] We do because different masters and continuous albums would be broken otherwise.

Can happend but it's can be considered has a mb db error and it's not a common case. And about differents master I think most of the people don't care and don't even have the audio system to ear the differences. So I would not implement a new feature only for this. And if we do, I will hide it so we do not increase ui complexity' But let's see what other people think o/

[deleted] Each file should be linked to both a recording MBID, a release MBID, and a tracklist.

In your previous comments you where saying a track should not be associated to a release mbid if it's a standalone recording..

[deleted] Users don't expect a file from a release to be used in another release, so supporting multiple audio files per recording is essential.

I don't see how it's confusing but in any case if there is no album tag we will use the album we have in db. If the album is not in db we will pick one randomly from mb db. But I don't see how this is related to multiple audio file per recording

[deleted]

petitminion Can happend but it's can be considered has a mb db error and it's not a common case.

Do you have zero experience on how MusicBrainz works whatsoever? I have been editing for about 8 years and I am repeatedly telling you why this is not true because this is not how MusicBrainz works. You do not want to listen.

petitminion And about differents master I think most of the people don't care and don't even have the audio system to ear the differences.

Right, but you don't get to decide whether that's true.

And Funkwhale should not coincide with your use case perfectly, you are only one user. The way you want Funkwhale to operate breaks the use cases of many more people than the ones it "fixes", which it doesn't even fix, it just makes it more convenient for people who have tagged their music incorrectly which is ironically the opposite of what you vouch for.

petitminion In your previous comments you where saying a track should not be associated to a release mbid if it's a standalone recording..

A track should be linked against every relevant combination of MBIDs it has stored, and matched to none of the ones it doesn't have.

This means that a file from one release should never be used on another release, and files which do not have a release MBID should be presented separately.

petitminion I don't see how it's confusing but in any case if there is no album tag we will use the album we have in db. If the album is not in db we will pick one randomly from mb db.

But this is you guessing what the community in large wants. Which I can already tell is wrong because MusicBrainz does not work like this.

petitminion But I don't see how this is related to multiple audio file per recording

A MusicBrainz recording can be associated with multiple releases, but a recording can be associated to multiple very different versions of the audio which only work played together if the rest of the files were retrieved exclusively from that release.

I keep telling you MusicBrainz recordings do not fulfill the purpose you want to use them for and you refuse to listen.

EDIT: Alright, I'm about done here. I honestly can't keep spending energy I do not have on this kind of behavior. It's not right for me to continue.

petitminion

[deleted] Do you have zero experience on how MusicBrainz works whatsoever? I have been editing for about 8 years and I am repeatedly telling you why this is not true because this is not how MusicBrainz works. You do not want to listen.

Plz provide technical information. I shared here the documentation of mb about recordings. I made some tests and I just can't find anything that prove that what you said is a common issue so plz provide proof if concept.

[deleted] The way you want Funkwhale to operate breaks the use cases of many more people than the ones it "fixes", which it doesn't even fix, it just makes it more convenient for people who have tagged their music incorrectly which is ironically the opposite of what you vouch for.

I agree it a can be a usefull feature. I just don't think it's common enought to worth the work but if you want to do a Mr and a design proposition feel free to create a new forum post with all the details. If not plz wait for the other team members that t will work on this to give their opinion

[deleted] A track should be linked against every relevant combination of MBIDs it has stored, and matched to none of the ones it doesn't have.

This means that a file from one release should never be used on another release, and files which do not have a release MBID should be presented separately.

According to recordings mb doc I linked before this is simply not true. Plz don't make me repeat the same things without giving proof.

[deleted] MusicBrainz does not work like this.

I was speaking of fw db : if a file is linked to various albums on mb db wee will pick in priority on that is present in fw db.

[deleted] I keep telling you MusicBrainz recordings do not fulfill the purpose you want to use them for and you refuse to listen.

My pov is that you refuse to listen to me because your are obsessed with your use case ^^' but I willing to listen if you will only prove what you said is really a common issue and it's not wrongly associated acoustid on the mb db

[deleted]

Alright, all that aside, I need to point out a problem we have here:

Picard can match a MusicBrainz recording's AcoustID to multiple files that are completely different.

However, multiple recordings can share a single AcoustID, and a recording can have multiple AcoustIDs matched to it.

Adding to this, minute differences in audio that in cult can be considered absolutely important to differentiate one track from another can very often not be represented by the AcoustID.

Funkwhale has no business guessing what recording to associate with a file in the first place. This has to be done manually, there is no system in place to avoid this problem and coding in a fully automated solution is impossible. The user has to be able to pick which recording matches the file best.

petitminion

[deleted] Funkwhale has no business guessing what recording to associate with a file in the first place. This has to be done manually, there is no system in place to avoid this problem and coding in a fully automated solution is impossible. The user has to be able to pick which recording matches the file best.

Acoustid is a system to avoid this problem but has any system their is humans erros in db. Has I said in the first post of this thread we could think a user validation but this is a lot of work and we are not a platform aiming to tag properly peoples audio files.

Another thing we could do is to give priority to the well tagged files in fw db : for now if fw has various file for the same track fw will choose the best quality one. During the import process, in the acoustid match, we could make sure to no import the wrongly tagged file if another one is already present on db (even if the new one has a better audio quality). This way the probabilities of errors decrease a little bit.

[deleted]

petitminion I made some tests and I just can't find anything that prove that what you said is a common issue so plz provide proof if concept.

I don't even know. You're making so much stuff up that I don't even know where to begin. It's like you threw the bible at me and asked me to provide a single proof that the whole thing is fake.

[deleted]

petitminion animaldaydream A track should be linked against every relevant combination of MBIDs it has stored, and matched to none of the ones it doesn't have.

This means that a file from one release should never be used on another release, and files which do not have a release MBID should be presented separately.

According to recordings mb doc I linked before this is simply not true. Plz don't make me repeat the same things without giving proof.

I am saying what the behaviour of Funkwhale should be. It is based on the functionality that MusicBrainz provides and I am aiming for Funkwhale to not break any music library.

[deleted]

petitminion animaldaydream MusicBrainz does not work like this.

I was speaking of fw db : if a file is linked to various albums on mb db wee will pick in priority on that is present in fw db.

The recording MBID of a release is not enough to link it to multiple other releases because the audio will not necessarily match.

[deleted]

petitminion Acoustid is a system to avoid this problem

It is not. It is meant to find a release based on similarity of audio files to recordings. It is not used for finding a specific version of an audio file. It is not a system to find an audio track. It is not used to match an audio file to multiple releases. It genuinely does nothing that you want to use it for.

You keep insisting that an AcoustID fingerprint can be used to identify an audio track and pair it to a recording in the MusicBrainz database. The fingerprint can not do that. It is a support in that it lets you find a release in the tagger if you have all the audio files to be matched, but it does not guarantee that you'll end up on the same recordings without further user input. And it does not guarantee that recordings are unique either, as it stores so little information about the audio file that small differences will not be picked up. It isn't even about transcoding either; audible differences in the audio that users can pick up are indeed not picked up by the fingerprint.

Really you shouldn't be asking here if you have no idea about any of this, or if you're not willing to listen to feedback for that matter. Go ask on the MusicBrainz forums for help.

I have to say something about your feedback: I am the only person here willing to reply to this post and I get no actual response to any of my arguments, you're just completely ignoring them and making up your own truth and it's honestly fairly disrespectful and really annoying. You keep on assuming how the system works by somehow making a fantasy in your mind about an utopian music database where all entities point to an exact audio stream without error unless some user has made a mistake, where in reality we as users don't have enough information to make a perfect database without access to enough releases from an official source to merge these recordings. And even then, the fingerprints also match when the audio does not.

MusicBrainz does not have the tools to fulfill the use case you want to "fix". It doesn't matter how much I say it though, it seems. It saddens me that it has come to this, and I'm seriously struggling to keep my composure.

I also have to point out nobody needs or wants this feature to be implemented whatsoever. It will only mess with the database in unexpected ways for the user that are not reversible while taking no user input to get there.

We are not prepared to tag music solely automatically. This is a job that is only possible to do by the user. AcoustID does not match audio tracks perfectly, end of story.

[deleted]

petitminion During the import process, in the acoustid match, we could make sure to no import the wrongly tagged file if another one is already present on db

How about you leave files without MBID alone? Now Funkwhale gets to decide if the uploaded file is worthy of the collection?

petitminion

About gappless playback plz see https://community.metabrainz.org/t/how-to-denote-gapless-audio-in-a-musicbrainz-release-entry/497861/65
and https://musicbrainz.org/doc/Style/Recording#Recordings_with_different_durations

The information about gapless play is not on mb db for now. And they do not seems to see a interest to add it for now because I understood gapless is related to a media type (cd, tape vinyl) and if the release is considered as one them, the player can use such info to delete the pregap.

About fw we could during import process give priority (at the album level) to audio file that where imported at the same time. This way mastering and audio gaps will be coherent. Eg if an import add all the tracks of a album, we use theses audio files (if there is a minimum quality of 320kbps mp3)

[deleted]

petitminion The information about gapless play is not on mb db for now. And they do not seems to see a interest to add it for now because I understood gapless is related to a media type (cd, tape vinyl) and if the release is considered as one them, the player can use such info to delete the pregap.

Then do not use MBIDs for this, maybe?

I have plenty of releases that are released digitally and are mixed. They're called mixed albums. They're not rare, actually they're extremely common in electronic music. Parts of the composition of any two adjacent tracks flow outwards from the limits of each track. They're extremely important from an artist intent perspective. If Funkwhale were to break this I would throw the thing into the trash.

You're willing to break gapless albums. I don't think anybody else is. If I ask anybody with an interest in music "hey, would you like your music player to mix up your tracks to make albums you're missing?" the answer would almost always be an absolute no.

[deleted]

petitminion About fw we could during import process give priority (at the album level) to audio file that where imported at the same time.

This is a good idea in theory, but then you also want to make up releases from bits and pieces of other releases and this would just break things further.

petitminion This way mastering and audio gaps will be coherent.

Use MBIDs for that, unless they're not available.

petitminion Eg if an import add all the tracks of a album, we use theses audio files (if there is a minimum quality of 320kbps mp3)

So who decides what codec and bitrate should be used, and why is it relevant at all?

petitminion

Here is a resume for other people :

Acoustid Fingerprint :

allow to match audio files to on or various recordings.
Is very accurate, each audio file has a unique fingerprint. -> matching errors are exclusively humans errors

Mb recordings :

can be matched to various releases.
can be matched to various audio files (slightly quality difference, mastering mixing but same music content). This can break gapless play.

Issues :

Funkwhale do not have a feature to allow users to choose between various audio recording for the same fw track.
How to choose which recording and release to link the audio file with ?

Solutions :

1.1 Do not implement a new feature but :

Select best quality audio track
Give priority to file that have been uploaded together to preserve gapless playback.

1.2 Implement 1.1 and a new feature to choose various audio source for a track

2.1 Try to match the release with the album tag if any .If not give priority to already existing releases in fw db.

Responses

[deleted] So who decides what codec and bitrate should be used, and why is it relevant at all?

We decide to give priority to best quality codec and bitrates. Unless a release is uploaded in batch with a minimum quality of mp3 320kbps (because this is enough for any home studio sound system)

[deleted] How about you leave files without MBID alone? Now Funkwhale gets to decide if the uploaded file is worthy of the collection?

This will depend on the pod admin (if he want to allow file not tagged with mbid). If the instances open to untaged mb files we could propose an option for the user to disable acoustid feature.

ps :
As I said before I will stop repeating myself. I will also stop responding to your point when they make no technical sense. Plz be respectful and stop making assumption of what I want, what I don't known or what I should do. The next time you insult me I will report you. If you have nothing new to say plz stop your harassment.

« Previous Page Next Page »