Bugzilla – Bug 188
Imported ID3V2 tags stripped when exported without metadata editor appearing
Last modified: 2018-08-20 11:45:27 UTC
Created attachment 95 [details] Fixes id3v2 tag recognition problem on import This should fix the "corruption" issues. What was really happening was that the import was assuming that if the file had ID3V1 tags, then it didn't have id3v2 tags and it didn't turn on the v2 indication in the tag class and Audacity would simply ignore any v2 tags. Unfortunately, libid3tag doesn't expose any way of determining whether the file really does have v2 tags or not, so, rather than modifying existing routines, I added another that simply returns the highest version tag set found in the file. Leland
I've looked into this a bit more. The import, which improperly identifies the version of tags, is definitely the issue here, but I'm wondering if my solution is overkill. It will certainly fix the issue, but there might be an easier solution. The Tag class maintains a flag that determines whether the tag format is ID3V2 or not. This flag defaults to TRUE and whenever the tags are cleared, it gets reset to TRUE. The reason there is a difference with tag handling during chain processing and when importing/exporting manually, is because the tag editor isn't displayed. You can prove this by going into preferences and disabling the Metadata Editor which will cause imported ID3V2 tags to be stripped when exported. There's actually a "bug" in the TagsEditor::TransferDataFromWindow() that doesn't maintain the V2 flag properly. It clears the tags and then repopulates them from the data in the dialog, but that clear also resets the V2 flag to TRUE, even if it was FALSE. So, that will need to be corrected as well. However, why bother worrying about whether the input file had only V1 tags or not? Sure, go ahead and load them, but if they get written back out, write them as V2 tags. This would be no different than if the user added tags to a file since the user doesn't have a way to specify whether V1 or V2 tags are written. V2 tags are simply always written. Leland
(In reply to comment #2) Leland, thanks for the fix. I had confirmed the fix worked OK on Windows 7 before I read this. > There's actually a "bug" in the TagsEditor::TransferDataFromWindow() that > doesn't maintain the V2 flag properly. It clears the tags and then > repopulates them from the data in the dialog, but that clear also resets > the V2 flag to TRUE, even if it was FALSE. So, that will need to be > corrected as well. However, why bother worrying about whether the input > file had only V1 tags or not? Sure, go ahead and load them, but if they > get written back out, write them as V2 tags. > > This would be no different than if the user added tags to a file since the > user doesn't have a way to specify whether V1 or V2 tags are written. V2 > tags are simply always written. I thought we only wrote v2 tags even now, because there are a small mumber of complaints that none of our tags are visible in apps that only read v1. Or is that only true if Audacity wrote the tags in the first place, i.e. if Audacity imported v1 tags then it would write those tags as v1? I think only writing v2 is fine, as long as Audacity can correctly "convert" imported v1 tags to v2. People can use command line export if they must have v1 tags (could you sometime add that dropdown to Specify Commmand Line Encoder to store entries, like we talked about before)? If we only write v2, can we ignore the bug in TagsEditor::TransferDataFromWindow() ?
(In reply to comment #3) The only time Audacity will write ID3V1 tags is if a file is imported that contains ID3V1 tags. That is the only time that the ID3V2 flag is turned off. If I remove the check for V1 tags on import, then V2 tags will always be written. And yes, if the imported file contains V1 tags, then libid3tag will automatically convert those to V2 tags automatically. I will commit a change that will remove V1 writing altogether so you can give it a try. We can always revert it if need be. Doing so will still correct this bug as well as bug #225. Leland
DEVEL-FIX MADE. r10979 removes any writing of ID3V1 tags. ID3V1 tags will still be imported, but they will be written as ID3V2 tags.
I think this is fixed now - tested on Windows and Ubuntu. Changing to RESOLVED - FIXED.
