Invalid 'File Cannot be Opened for Writing' when padding bytes are missing (Mp3tag V3.11 on Windows 10 64-bit)

I have been receiving numerous messages 'File XXX Cannot be opened for writing' when updating my Wav files with Mp3tag - irrespective of whether it’s updating a tag (e.g. Convert-> Filename -> Tag), Auto-renumber Tool, or some other operation. I have not been able to establish a pattern or reason until now.
I've checked the effective file permissions, and the files being opened concurrently in another process, and similar factors as possible reasons for the error message, and have eliminated all those. After lengthy investigation, I've found that the problem happens consistently when the input file in question is missing the padding bytes which need to be in place for word alignment of the LIST/INFO INAM, IART, Ixxx etc. tags. After fixing the file (see detail below) so that the padding bytes are correctly inserted, Mp3tag always correctly updates the file(s) in question. That is, on my system, the problem is now reproduceable and fixable.
There are numerous items on the Mp3tag support forum regarding this error message, with most replies being along the lines of 'check your file permissions', or 'check it's not also open in another program such as Windows Media Player'. Many of these items are closed with inconclusive resolutions or workarounds
I don't know why Mp3tag issues this message in response to this situation - I can speculate that it's getting confused and misinterpreting the following tag ID as a length field, and consequently trying to open an output file which is bigger than allowed - hence the error message. However, the exact sequence of events is not central to the issue (for me).
The error message is quite misleading, and leading many people to bark up the wrong tree. I'm requesting that Mp3tag be changed to properly check the integrity of the LISTINFO chunk and its tags, and issue an accurate and informative message if the padding bytes are missing, along the lines of "incorrectly formatted LIST/INFO metadata: padding bytes missing".
Even better would be for Mp3tag to be tolerant of this situation, and even better better to insert the padding bytes so that the file is formatted correctly. Obviously it cannot be held responsible for badly behaved programs which build the files incorrectly but, hopefully it could detect and report the problem or, even better, to insert the missing padding bytes.
In my case the incorrect files have been built with Ashampoo Burning Studio 20 - Version 20.0.4 (paid), as a result of ripping from my CD collection. I know that the problem has been fixed in Ashampoo Burning Studio 2021 - Version 1.22.6 (free), probably as a result of the latter seeming to rely on ID3 tags rather than LIST/INFO tags. Other than that, I haven't investigated further as to which versions of Ashampoo do or do not exhibit the problem. The data portion of a given tag field might be an even or odd number of bytes, which means that, if using one of these programs, there's about a 50/50 chance that the problem might occur. When it does happen, it also confuses Windows File explorer, so that sometimes it displays the meta tag data, and sometimes not, assuming you have requested the relevant metadata columns to be displayed.
Given that I've already ripped my large CD collection and haven't encountered the problem until recently, re-ripping the whole lot is not an option. Instead, I've written a C# program which descends a specified directory, and does a bulk file analysis, reporting and fixing of the missing padding bytes.
I've placed two files onto Google drive, with which you should be able to reproduce and analyse the problem (i.e. Mp3tag issuing the bogus message). These are located at Mp3tag_Problem – Google Drive
Turtles_Happy Together_Bad.wav is a badly formatted file produced by Ashampoo Burning Studio 20.
Turtles_Happy Together_Good.wav is the file output from my program after reading the first (BAD) file, inserting the padding bytes, and adjusting the relevant length field values - it works correctly with Mp3tag.
In the case of this file, the padding bytes were missing from INAM, ICRD, IGNR, ICMT, resulting in a net length increase of four bytes for the corrected file. By using a hex file dumper, you will see that the only differences between the two files are (A) inserting the padding byte at the end of each of the four tag fields and (B) adding the aggregate extra length (i.e. 4) into the LISTINFO length field, and into the length field of the RIFF header (i.e. offset 4 in the file).
I'll be most interested in your comments, especially if I've been barking up the wrong tree.
Having said all that, I must say that, as a new user of Mp3tag, I’m most impressed with the functionality and capability of this program, especially considering it seems to be the work of a single developer, is offered as freeware, and the developer also maintains a good support/forum web site. And, of course, if this is fixed, I'm more than happy to donate.

Thanks for the detailed analysis of the issue and the example file. It's clearly a broken INFO chunk that is missing the padding byte for some of its subchunks.

I'll try to come up with something and will keep you posted.

Thanks, Florian.

Happy to help with further info or testing if needed.


1 Like

I've added a workaround for those missing padding bytes with Mp3tag v3.12a.