Are you sure that the player not only has closed its main window but also that the player process has been closed down?
E.g. WMP runs a background process for quite some time while it is updating the database.
So please check the task manager showing processes of all users and verify that the player is gone before you continue to edit the tags.
What does it look like then?
about task manager im not able to see any more related process to the player after. In any case i strongly doubt that the file is still open if u play for 15 secs another file.
I tag thousands of files, I'm a dj. well, using FLAC and mp3 I can edit the tags even while the song is playing. I can get "access denied" sometimes while savin the tags and the song is playing, for instance when i load a picture big in size. But i never get stuck.
Using ogg is deterministic. It looks like the "ogg routine" puts an internal lock on the file when passed to the player, being not able to release it anymore.
UPDATE: after 13 mins of stuck, mp3 saved the edited tag.
What I mean (sorry abt my bad english) is that mp3tag get frozen whe you try to change focus from the tag edit box (i usually edit the tags in the main "list" window), but after 13 mins it is able to go back to normal behaviour.
Well, i stopped avast for 1 hr, then downloaded handle.
When you launch mp3tag and just load some music files in mp3tag, no handles on those files.
When launching the player for an ogg file I see 3 handles for that file, 2 belogining to mp3tag, one to AIMP (my player), then i close AIMP and I see only the 2 handles belonging to AIMP. From now on if I try to update the ogg tags I get stuck (probably frozen for many minutes).
I searched the file handle globally and specifically: the object (for instance: handle64 mysong.ogg) and the processes (handle64 -p mp3tag, handle64 -p aimp).
When I launch the player for a non-ogg file (mp3, flac, ...) from mp3tag, I don't see any file's handle belonging to mp3tag, just the AIMP's handle.
So it looks like mp3tag is managing the ogg in such different ways.
I can send screenshots if it helps (don't know how).
What it shows: the file is (still) blocked by the player.
So the only way around this is, not to run the player simultaneously on the files that get edited by MP3tag.
This is no bug, I would say.
The problem is that more than one program access the files.
If you call the player from within MP3tag then MP3tag is sort of a host for the player program.
And if MP3tag should modify a file, naturally, there has to be a handle. But there must be only one program (in this case MP3tag) that creates the handles.
All this was to show that it is not only MP3tag that access the files but that the player(s) also keep their handles open and this then blocks MP3tag from updating the tags - which was your original concern.
As updating tags could mean that a file has to be rewritten it would also mean that while keeping the player open, you would snatch away all the access parameters and the player would certainly be irritated if it had to resume playing. Therefore players block files. (WMP for instance always blocks the current file and the previous file - which can be seen in a process explorer).
So the only available cures would be:
try to influence the player programmers to simply read files without blocking them or
modify your workflow so that you avoid playing and tagging at the same time.
Thx for your effort in replying me; first of all please accept my compliments to you all for mp3tag, a small software masterpiece: my workflow (editing tags while listening) is mandatory; while I'm listening for the first time hundreds of songs I need to classify them in many ways for my gigging purposes. I extensively use comment and grouping fields. Also I discogs-correct all the traditional metadata. It's a hard job believe me, and mp3tag perfectly fits my needs. I find exceptional many mp3tag's features, not to mention mapping, scripting, customization of views. Said that, thanks again to you all.
Going to the point: I totally agree about handles explanation (b.t.w. by profession I'm also a Senior ORACLE DBA and Linux Systemist), but still can't understand so many things:
mp3tag + AIMP allows me to modify any tags for any sound file types (but ogg), even while playing. I tipically get a small playback while saving or a "can't access" when the writing is "massive" (typically when I update/insert the cover pictures). That's perfectly acceptable. But why it doesn't work for .ogg?
Assured that the player released the handle of the ogg, (I assume you accept that loading and playing another song the first file is released by the player, and more when the player is process-tree terminated) why mp3tag still "sees" the file locked for a very long time?
May I ask you to make the same tests? This can avoid any issues linked to my system's setup.
We can discuss this back and forth for some time. The only reliable source of information whether the player was really terminated or not is a process explorer or the handles program linked above.
MP3tag gets the information about a locked file from the OS.
Your observation that you sometimes cannot access MP3 files is probably accurate as files usually only have to be rewritten if the already exiting padding for tags is not big enough.
So if you have already tagged files to the greatest extent and now do the fine tuning, the padding will probably suffice. But even that cannot be guaranteed as you do get "cannot access" messages.
Perhaps the combination of MP3tag and your player(s) is not the best for that workflow that you find mandatory. Perhaps changing to foobar2000 is a better choice as this program can tag and play out of one box.
FYI, after a lot of struggling, I've finally discovered that the "Web Media Extensions" are the cause of locking the .ogg files. This wonderful 16KB of piece of software by Microsoft can undefinetely lock ogg files !!! Removed, now I work flawlessy.
Googling it's plenty about that. I discovered that because even moving the OGG files can be a mess.