# Error message: cannot be opened for writing

I have several folders of FLAC files which stubbornly refuse to be edited with mp3tag - I get the dreaded "cannot be opened for for writing" message no matter what I do.

I have access/ownership rights, I've copied them and tried to edit on 2 different machines (W10 & W7) - I can edit the tags using MediaMonkey, but not mp3tag or Metatogger.

This problem seems to be a somewhat common one and it appears it was even reported as a bug here: /t/17857/1 yet for some reason it was closed as "No Bug"?

Is there no straightforward solution to this problem?

Yes: close all other programs that might be interested in the current file.
And just to get this clear: this is a message issued by the OS. MP3tag is just the messenger (who shouldn't be hanged for it).

See here: File... cannot be opened for writing

thanks ohrenkino,

So I rebooted my machine and opened mp3tag - nothing else is running except ESET Smart Security and a very few startup programs - Windows Explorer is not running, neither is any browser open.

I still cannot edit the files in question. The fact that a second tagging program (Metatogger) can't edit these files supports your assertion (to some degree) that its the OS causing the problem. However, why only these few files, and why can MediaMonkey edit the tags?

What I did with one of my problem folders was open all files in MediaMonkey, edit just one tag field for each file, then try the same files again in mp3tag - now the tags can be edited with no error. I believe another user here did something similar using foobar.

Clearly something is going on and its not enough to say "this is a message issued by the OS" - that may well be true, but what can be done about it? What I did is not exactly a straightforward solution; its rather time consuming and it'd be nice to find the root of the problem.

I'm no programmer, but if MediaMonkey can open these files for editing, can mp3tag not be modified somehow to do so as well?

As far as I remember, you want to have a

And you also stated that you don't agree with the "no bug" rating.

I would say that now we have the proof that apparently there is no straightforward solution and each case has to be treated individually.

In your case it looks as though you have some corrupt files and you even seem to have a remedy for that.

The question why some programs have features that others don't have is something I cannot answer. My oberservation is that if the files and the environment are OK, then you can tag them with MP3tag.

And yes, perhaps it was a bit bold to blame only the OS.
On the other hand: why should a tagging program rectify the blunders of the ripping process?

I fail to see how you came to that conclusion.

Maybe.
That message appears if the file path has too many characters.
Re-name the problem files with a very short path and try again.

thanks ryerman,

I copied the folder to the root directory so the folder & file names shouldn't be too long - still no luck.

I would hardly call what I did a "remedy" - like I said, its rather time consuming and it'd be nice to find the root of the problem.

What I'm hoping to do is address a concern that I, and at least a few others here, have had with certain files. I'm having a hard time accepting the idea that they are "corrupt" files - they otherwise play fine and can be worked with by other software.

mp3tag has been a very useful tool for editing tags, so I'm not looking for a solution elsewhere - I'm really hoping I can find some an answer here. Perhaps its not a "bug" in the program, but then again, maybe there's an improvement that can be made. Or maybe we're just missing something...?

How long is the path?
Post the actual path and attach an entire problem FLAC file.
You can attach the file to your next post or provide a link to a file sharing service.

foobar apparently allows you to check the integrity of flac files: http://www.foobar2000.org/components/view/foo_verifier

So perhaps you try that utility on the unwilling files and see if you get any hints if and what is wrong.

The path is:
z:/1963 Bobby Vee Meets The Ventures/01 Goodnight Irene

yeah, I know, I'm going way back...haha -- and I checked the integrity with foobar as per ohrenkino's suggestion - it checked out fine.

The file is 13.9MB, so it looks like its too big to upload here? Not sure what kind of file sharing service you'd suggest - that's a new one for me.

Sendspace is easy to use: https://www.sendspace.com/

Okay, I uploaded the file to sendspace - the link is https://www.sendspace.com/file/uxl5y3
let me know if it works.

thanks

I can reproduce the behaviour you have reported.
My best guess is that the embedded picture was added to the wrong location in the file.
But I'm not getting into a discussion about how this should be handled by Mp3tag.

MetaFlac (the command line utility, see here: https://xiph.org/flac/documentation_tools_metaflac.html) reports that the picture in your file is in Block 0.
But the standard requires the picture to be in Block 6.
Block 0 should contain STREAMINFO (bitrate, number of samples, sample rate etc.). see here: https://xiph.org/flac/format.html#metadata_block.

Neither Winamp nor MetaFlac can remove the embedded picture, as they do for a correctly embedded image.
Winamp will edit the other metadata but that does not cause the file to be writeable in Mp3tag, as you reported for MediaMonkey.

You've found 1 solution to the problem. Here's another:

1. Copy the file using ffmpeg (https://ffmpeg.org/) command line:
ffmpeg -i "W:\Path\to\original file.flac" -acodec copy -map_metadata -1 "W:\Path\to\FIXEDoriginal file.flac"


This will copy the file without re-encoding and remove all metadata. (the command can be adapted as an Mp3tag Tool)

2. Add the FIXED file to the Mp3tag file list.
3. Use Tag Copy and Tag Paste on the context menu to write the tag from the "damaged" file to the FIXED file.

But my best advice is to stop embedding album art with whatever was used for this file.

thanks ryerman,

I didn't know FLAC files could have embedded pictures in them - and I'm not sure how you figured out which "block" it was located in, but thanks very much for the info. And it seems ohrenkino was right that these files could be considered corrupted - or at the very least non-standard. I've no idea who ripped them or what software was used - I downloaded them as a torrent some time ago.

I ended up trying something a bit different with the files - I used xrecode to re-encode the files using its default settings for metadata. The new files were encoded correctly - at least mp3tag was able to open and edit them. It seemed like a fairly simple approach.

Thanks again for the help.