Tag visibility in Windows Explorer
Fretless14 opened this issue · comments
So I've scavenged EVERYWHERE looking for a solution to having Mutagen ID3 tags show up in Windows explorer - it was crucial to an app I'm working on. Turns out Windows is super picky/buggy with how they handle tags. They only look at the LIST chunk of type INFO. Also, I'm pretty certain the order of the LIST INFO chunk in relation to the ID3 chunk matters. Maybe I should test just to make certain but it's not of high priority to me rn :)
Here's a script I made in order to use the mutagen id3 tags and convert them to the LIST INFO tags, and insert them in the correct order (again not certain on the fact the order matters, but I'm pretty sure it does based on what I've seen around the internet and my work trying to figure this out).
Mutagen_Wav_Windows_Compatibility.txt
This isn't as nice as editing/implementing the mutagen files directly, but I tried looking at them and it took me way too long to try to understand how things were working (I wouldn't say I'm very experienced). In order to use this, just import it and call
Mutagen_Wav_Windows_Compatibility._make_mutagen_tags_Windows_readable(filepath, id3_tags)
This assumes you already have the id3 tags written in the file (it won't write the id3 tags), but will write the LIST chunk equivalent tags right before the id3 tags if there are any, at the end of the file.
It does overwrite the file you put in, just so you know. Make sure to make copies before you use this.
If anyone has any suggestions on improvements or wants to implement this into the mutagen package (it fits right? Or is mutagen solely for ID3 tags and the LIST INFO chunk is irrelevant as far as the purpose of Mutagen? I think I saw a bunch of people asking for this but the go to answer was just saving the tags in v2.3, not really addressing the issue), please do!
I still need to check if MP3 and FLAC are readable on Windows, if not I can add to this file and update it here.
I'm also new to GitHub so if this is in the wrong spot/should be somewhere else, lmk haha.
Best of luck to those using this!
-Michael
Also, I'm pretty certain the order of the LIST INFO chunk in relation to the ID3 chunk matters. Maybe I should test just to make certain but it's not of high priority to me rn :)
Could you summarize your findings/guesses in text form? It's hard to extract from the code.
I think I saw a bunch of people asking for this but the go to answer was just saving the tags in v2.3, not really addressing the issue), please do!
Afaik recent Windows 10 can read v2.4, so, yes, that shouldn't change anything anymore :)
I'm wondering if we could use pywin32 or similar in CI to verify via the Windows API what Windows can read.
This isn't as nice as editing/implementing the mutagen files directly, but I tried looking at them and it took me way too long to try to understand how things were working (I wouldn't say I'm very experienced).
You might want to look into the INFO chunk handling in https://github.com/metabrainz/picard/blob/master/picard/formats/wav.py#L39-L219
This is using mutagen's RIFF chunk handling to add and modify the INFO chunk. I did not look into your code too deeply, but e.g. I could not see it updating the sizes of the surrounding container chunk, so this might actually break files.
I wasn't yet sure how to best implement this to include this functionality in mutagen directly. I imagine it working somewhat similar to e.g. legacy ID3v1 handling, where mutagen optionall can write RIFF INFO from existing tags. Or maybe just expose the RIFF INFO somehow and let mutagen users handle that. @lazka maybe has some ideas how to do that.
Also I think this issue is basically a duplicate of #207, which is about adding RIFF INFO support to mutagen
This isn't as nice as editing/implementing the mutagen files directly, but I tried looking at them and it took me way too long to try to understand how things were working (I wouldn't say I'm very experienced).
You might want to look into the INFO chunk handling in https://github.com/metabrainz/picard/blob/master/picard/formats/wav.py#L39-L219
This is using mutagen's RIFF chunk handling to add and modify the INFO chunk. I did not look into your code too deeply, but e.g. I could not see it updating the sizes of the surrounding container chunk, so this might actually break files.
I wasn't yet sure how to best implement this to include this functionality in mutagen directly. I imagine it working somewhat similar to e.g. legacy ID3v1 handling, where mutagen optionall can write RIFF INFO from existing tags. Or maybe just expose the RIFF INFO somehow and let mutagen users handle that. @lazka maybe has some ideas how to do that.
Currently it works the user supplying the mutagen wav.tags property, converting them into INFO notation (as an object), finds the id3 and INFO indexes, parses the existing INFO tag data into an object, merges the old and new with the new INFO object taking precedent, removing the id3 and INFO chunks, and writes the new INFO object and id3 chunk (unchanged) to the end of the file, with INFO coming first and id3 remaining last. The INFO chunk size is recalculated from the merged INFO object and packed into the data.
I basically copied the format of what I saw from MP3Tag, I saw it works so I mirrored that format. Through writing the code and searching online (maybe somewhere in the mutagen issues or the the exact issue you tagged), the INFO and id3 tags might need to be in a certain position and/or order in order for Windows to read them properly. This is speculation though I’ll have to mess around and see what happens.
This was also my first time ever reading/writing the binary of a file, let alone wav and how it’s structured, so there may be some things I didn’t pick up on. For example, I saw MP3Tag simply add the INFO tag at the end with the LIST container along with it, when there was already a LIST container from some Logic Pro data. I wasn’t sure if you just add the INFO tag inside that container or just make a new LIST container? The way I wrote it seems to work so I assume it’s fine which is adding a new LIST container for type INFO. I also thought maybe since there isn't a size subchunk for the type of LIST container maybe you always need multiple LIST chunks if you have more than one type (eg. adtl)?
This code also allows for mismatching id3 and INFO tags, which probably isn’t good. You supply the id3 tags instead of reading them, this way if there isn't any, you can still add the LIST INFO tags. So if you supply the wav.tags property and it’s different than the id3 tags already in the file you’re editing, the INFO tags will differ from the already written id3 tags. Ig there’s a simple fix of overwriting the id3 tags with the one you supply.
Also sorry accidentally closed this thread lmao
I'm closing this in favor of #207. There is also the proposed patch in #538 to add read support for the INFO chunk. This could be extended with some ideas from https://github.com/metabrainz/picard/blob/master/picard/formats/wav.py#L39-L219 for more supported tags and write support.