![]() But give the casual user a bit of feedback why the command can not be executed. That is in itself an excellent approach, don't mess with a damaged file to avoid more problems. Now I understand that it is not that the program is not able to write the files back again, it is merely that you decide not to do so because of the risk of adding more crap to a file that is already somewhat damaged or lacking the proper structure. Also, if the alert was a bit more informative than just mentioning that the file could not be written - that would be a good thing too. Perhaps it is also an idea to clean up the thread, rather than newcomers going through all the replies that point in wrong directions. That would save a lot of time investigating if it has anything to do with ownership, rights, file locked by other processes, security settings, as is also suggested as possible causes in this long thread. So that you know something is wrong with it. I suppose when the software reads the files to find the tags, it can already detect issues with integrity and it would be nice if they were labelled with a mark or shown in red. And when they show up in MP3tag, most of them showing tags just fine, it is for a casual user not obvious there is something wrong with the file. Thank you, ok, did some checks following your instructions, and indeed some of the MP3 files had issues, although they played fine. If anyone encounters a similar problem with a WAV file, I would recommend trying the same (or similar) method - I think it should help. FLAC-compressing and decompressing it resulted in the resolution of this problem - I hypothesize that it happened thanks to getting rid of the problematic extra chunk of the file. Taking all of the above into consideration, I believe the problematic file must have had some kind of glitch in its structure - the 16 additional bytes - beyond the actual audio data - which prevented Mp3tag from processing it correctly. No wonder, since when I checked their size, it turned out that the original file is 16 bytes longer than the one which emerged after compressing the original one to FLAC and decompressing it. However, Duplicate Cleaner did not show the files to be identical. The foobar2000 Bit-compare tracks tool did not report any differences in decoded data, either. Now, when I compared the original WAV file and the one created after decompressing from FLAC, the EAC compare tool did not show any differences whatsoever. This time Mp3tag created a tag for it (for the decompressed file) without any problems. However, trying to tag it in Mp3tag always resulted in the same error message.Īfter trying various things (like resorting to a backup copy of the same file, etc.), I tried something similar to what someone described above: I compressed the file to FLAC and then decompressed it. When checking its integrity, foobar2000 did not report any problems. The problematic file played fine in foobar2000 and could be copied to other disks without any problem (the issue wasn't disk corruption then). ![]() The rest of the files in the same folder did not get this message and were tagged just fine. After having done over 2000 files successfully with Mp3tag (what a great tool it is!), I came across one WAV file which kept getting the message "File Cannot Be Opened for Writing". I want to share my experience because in this case I believe the problem didn't have anything to do with Windows security, permissions, etc., but with the integrity of the file. I came across this thread after I encountered a similar problem with a single WAV file. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |