Save metadata on the same file, not in another

[JosueChG]

Hi, I started editing the mp3 tags using mp3agic and it worked well.
But I am a little dissapointed that when the metadata is to be saved it has to go to a new file, not the same file.
I know that to save the edited tags in the same file is possible as VLC, Winamp and other programs do it. And I want the program I am doing to do it as well.
Is that possible using mp3agic? if not, can you suggest me another library that is able to do it?
I hope and thank your answers.

[mpatric]

Sorry to disappoint you. What applications typically do is save the file with a different name, then delete the original file (or rename it to something else) and then rename the newly saved file to have the original filename.

For example, if you open a file called foo.mp3 and change then meta-data then want to save it with the same name, foo.mp3:

• save it as foo.mp3.new
• rename foo.mp3 to foo.mp3.bak (or delete it)
• rename foo.mp3.new to foo.mp3

This is very straightforward to do and shouldn't be a reason not to use mp3agic.

See issue #8

[JosueChG]

Many thanks for your answer, but I still don't understand it.
I remember that when I am playing a track on Winamp and at the same time am editing the tags, when I save them, the track is still playing! can't understand how is it possible for a file to be deleted and a new one to replace it while the original file was still being played? How does the program deal with the annoying error message by Windows when trying to delete a file that is in use for another application?

[ahristov314]

Of course it's NOT a OS restriction. It's just bad design : when writing the new mp3 file, the MPEG frames are copied from the old one, (in the saveMpegFrames method ), so if both the new and the old file are the same, there's nowhere to read from because the file gets truncated on creation. A better approach would have been to read the frames in memory, THEN write the file. It's not like we're talking about Gb-sized files. Or if the memory is such a huge concern, it could have been the library the one creating the temporary file, or - even better - shifting the bytes in place as needed (forward or backward) to adjust for the change in the metadata size.

[ahristov314]

What I don't understand is why the developer, knowing what the issue is, would blame it on the OS.

Anyway, here's a fix. Took just one hour:

#202