So you basically want a component that adds a audio hash for the raw PCM/data from the decoders, right?
It would need to scan every file at least once, and then it would need to store the hash somewhere. And then I'm not really sure how it would display it, if it were not stored as a normal metadata field.
Well, as I said, I don't want hashes stored in the tags anyway, so that wouldn't help me very much... If I were to do it that way, then I actually wouldn't even be using customdb at the moment: the reason I AM using the component is because, FLAC for example, doesn't (yet) have some standard fields which I make use of in customdb officially specified.
Hi. Is there a way to access a hash (of any kind), or actually just any way to identify the actual audio of a file?
I'm using the customdb component, and it needs key(s) in order to know which tags goes to which tracks.
Is there a (compelling) reason why you don't want to store the hash metainfo in a metadata field, but rather insist on some other "official" solution?
That said, this problem might be interesting and easy enough to hone my f2k-component coding skills.
foo_biometric can write audio fingerprint to tag
can you use path?$crc32(%path%)maybe append subsong index in case you use cue sheets or chapters and similar?
One other reason why I don't want to store things in the tags is because that means I'll have to do that for anything new I ever rip / download.
It would be much easier if some sort of identification was available directly.
Actually, I think even the value of the first or last non-null byte of the audio would be enough, because I can couple it with the sample count (and the sample count (%length_samples%) of a file does crash with a few other files in my collection when only using that as the key with customdb, but not many at all).
Quote from: Kohlrabi on 28 October, 2012, 07:17:40 PMThat said, this problem might be interesting and easy enough to hone my f2k-component coding skills.I would really appreciate the help!
How is that affected by where this information is stored?
What does "directly" mean? Hash it on-the-fly? That seems excessive and highly impractical.
I'd prefer CRC
Quote from: Kohlrabi on 28 October, 2012, 07:17:40 PMHow is that affected by where this information is stored?Because actually storing a hash in the file means it'll have to be done manually for everything I open? Even if that could be automatically done, I just don't like it...
Quote from: maruseru on 29 October, 2012, 02:22:06 PMI'd prefer CRCHmm. Problem: Many possible collisions -> Different audio files could have the same hash values.A hash should be at least 64 Bits long to avoid probality of such collisions.