Add WavPack MD5 metadata support - #717
Conversation
- Parse WavPack MD5 metadata sub-blocks from real files - Support both standard and alternate MD5 block IDs - Scan later blocks when MD5 is not stored in the first block - Match Mutagen's FLAC md5_signature API for compatibility - Add focused tests plus real-world validation coverage
|
I investigated the 2 remaining failing checks (ubuntu-latest 3.10 and ubuntu-latest 3.12) and they appear unrelated to this WavPack change. Both are the Build docs step, failing with: duplicate object description of mutagen.flac.FLAC.info, other instance in api/flac I reproduced this on the PR branch and on origin/main with the same command:
Result is identical on main, so this looks like a pre-existing docs CI issue rather than a regression introduced here. For this PR specifically:
Could this be merged with awareness of the existing docs CI issue? |
@audiomuze Unfortunately not, and that is where we finally need some decision. The build fails because the docstring of the new attribute references Problem is that I personally think we actually should make this part of the API, though, especially if we have a second implementation of it. I think this is metadata for those files that is commonly used. And the property has been around for such a long time and is not going away anyway, so why not also make it official part of the API? Alternatively for this PR we could just not have the docstring referencing @lazka , what's your take here? |
|
I would just not reference it, since I don't think it was meant to be public and is just there to write it back. On this PR: What is the motivation for reading the MD5 in the first place? We don't read audio data in mutagen, so I don't see much use for it. |
|
My motivation for reading the MD5 is the same for FLAC and WavPack. As it's a MD5 of the audio stream it can be used to reliably detect duplicated tracks across a user's music collection irrespective of tagging, filenames, file size etc., whether searching for individual tracks or albums . For albums I concatenate the sorted MD5's of all tracks in a folder and compare it against the same for every other folder in a directory tree. Puddletag also uses it to be able to show duplicate tracks in the tagger. In addition having the MD5's stored in a database along with other tag metadata e.g. a bliss_analysis tag derived from the output of an audio analyser enables user communities to share analysis metadata, avoiding the need to re-perform analysis someone else has carried out previously. I vaguely recall a time many years back when I believe it was documented for FLAC - I recall seeing it in what I think is this page.
I agree, I can't think of any reason not to document it, and I think its inclusion enhances rather than detracts from Mutagen . But if If I must remove the reference in docstring to get the PR merged I'll do so. Either way, I'd appreciate a final steer to move this forward? @lazka? |
|
As requested, I have updated this PR to remove the FLAC attribute cross-reference from the WavPack docstring. |
|
ok, some way to identify duplicates sounds like a valid use case we can support, as long as it doesn't mean parsing the whole file by default and slowing down normal metadata operations too much. |
|
So this going to be merged? I’ve got downstream code that would like to leverage it. |
3 participants
This adds WavPack MD5 checksum reading to WavPackInfo.md5_signature, matching the FLAC API shape for compatibility.
It supports both WavPack MD5 block IDs (0x26 and 0x29) and scans later blocks when the checksum is not stored in the first block.
Validation: