> Picard already adds an "AcoustID" to mp3 files, so perhaps this could be
> used? (AcoustID doesn't appear to be added to all file formats,
> unfortunately, but "Musicbrainz recording ID" does seem to...).
I implemented chromaprint, the fingerprint library for acoustID, for
1.12. In Mixxx we can use it for all fileformats that we support. I also
thought about using it to uniquely identify tracks but for this to work
we would need to calculate this with the library scanner which will
slow it down significantly. A lot of our user already have huge
libraries and the scanner takes to long for them. (we need about 1s
reading the audio and 250 ms calculating the fingerprint, so for a small
5000 tracks library we would already need ~ 1h 45m)
> If this isn't feasible, then simply storing the md5sum of the audio data
> in the track as the track ID in the Mixxx database shouldn't be too
> resource hungry.
Calculating the fingerprint is not that much of a problem. Reading the
actual audio kills us. We also cannot read the whole file in binary and
just hash that because the ID3-tag is part of that and we don't want to
be affected by changes in them. Having to do this every time we rescan a
folder to check if nothing changed just takes way to long.
It is a nice idea and I would love to have it but we need to find a way
to deal with the I/O bottleneck
> Picard already adds an "AcoustID" to mp3 files, so perhaps this could be
> used? (AcoustID doesn't appear to be added to all file formats,
> unfortunately, but "Musicbrainz recording ID" does seem to...).
I implemented chromaprint, the fingerprint library for acoustID, for
1.12. In Mixxx we can use it for all fileformats that we support. I also
thought about using it to uniquely identify tracks but for this to work
we would need to calculate this with the library scanner which will
slow it down significantly. A lot of our user already have huge
libraries and the scanner takes to long for them. (we need about 1s
reading the audio and 250 ms calculating the fingerprint, so for a small
5000 tracks library we would already need ~ 1h 45m)
> If this isn't feasible, then simply storing the md5sum of the audio data
> in the track as the track ID in the Mixxx database shouldn't be too
> resource hungry.
Calculating the fingerprint is not that much of a problem. Reading the
actual audio kills us. We also cannot read the whole file in binary and
just hash that because the ID3-tag is part of that and we don't want to
be affected by changes in them. Having to do this every time we rescan a
folder to check if nothing changed just takes way to long.
It is a nice idea and I would love to have it but we need to find a way
to deal with the I/O bottleneck