Not calling MP4Close after MP4Modify corrupts an m4a file about mp4v2 HOT 6 OPEN

this is not a bug. documentation states that MP4Close writes out any pending 
changes.
You want this behavior to prevent unnecessary writes while the file is being 
changed.

I don't possibly see how that's a desirable behavior, and if what you're saying 
is
true, then forgetting to call MP4Close shouldn't corrupt the file.  I concur 
with the
OP; it seems like an obvious bug.

This seems like a pretty serious issue to me, yet there has been no news for 
almost a year. Are there any plans to fix this?

I could still easily reproduce this with the newest r390 revision. The link to 
the sample M4A file in my previous post is dead, but it seems to apply to all 
M4A files (and probably even to all MPEG-4 files), so that doesn't really 
matter.

tdebaets,

It does seem like a serious issue, and I'll try to look into it when I get 
time.  If you can, any debugging you could do on your end would help me isolate 
where the problem is.

Thanks

I'm afraid that the next 2 months will be too busy for me to do any serious 
debugging myself. Also, without any knowledge of the MPEG-4 format or the mp4v2 
code, it will be hard for me to know where to start. But if you want me to just 
quickly check some things, you can usually find me in #mp4v2 on freenode.

still a problem. another nice example is calling the unimplemented mp4subtitle 
--import routine, which begins by calling MP4Modify. it realizes it has no idea 
what to do next, quits, and leaves your file ruined.