It may be a good idea to have a look at the forums and the issue tracker, to see if you'd also want some change that others already asked for, see if others have the same issues and what workarounds are known, or simply to add your 2 cents to some discussion already started.

The MP3 Diags blog was used initially for reporting issues and sending feedback, but now it's mainly for new release announcements.

I strongly prefer the issue tracker and the forums, but you can also write me at (domain: gmail.com, account: mp3diags.) I suggest putting MP3 in the subject, for better spam handling. Also, if you write me, please make sure that my reply won't get thrown out by your spam filter. Currently the email traffic is low enough that I reply in a timely manner to all the messages I get; so if you expect a reply from me and you don't get it, it is because a message was lost. So better just use the forums, which guarantee that neither your messages nor mine are lost.

Should you encounter something similar, it would be a good idea to let me know about it, so I can fix the error that caused it. I need to know at least the file and the line, but what would really help is a reproducible sequence of events that triggers the assert. System information might be relevant as well. After the first crash an option gets enabled that causes many actions that occur to be logged to 3 files. When restarting after a crash, you are asked to send those files to help fix the problem. This logging can be disabled from the configuration dialog, by unchecking Log program state to "_trace" and "_step" files". Logging is disabled automatically when updating to a new version.

Getting the assert window to show up is tricky, so if you find that MP3 Diags just crashes under some circumstance, you may get additional information if you run it from the command line (or redirect its output.)