Well, I used MP3checker and that indicated VBR for the corrupted file.
Writing meta data TAGs to the audio files is used by hundreds of users, including myself on over 150.000 tracks! No one ever reported such an issue - as such I am pretty sure and very convinced, that this is not related to ProppFrexx at all!
I also never experienced, that writing TAG data causes such a heavy IO load, as it is only used to write TAGs when you modify them, but what you explain is TAG reading!- which of course has to initially take place to initially read the meta data of all your library tracks - but this happens independently of the "Save metadata to audio tag" option. So this can also not be related
I guess we should be careful here to not mix up things and create confusion.
And even heavily reading TAG data from your files shouldn't be a issue for a modern and fast IO subsystem.
When you already experience audio drops at this point, you might read this post:
https://www.proppfrexx.radio42.com/foru ... ?f=5&t=915
However, back to your problem: It seems to be a fact, that something has modified many MP3 frames of that file - looks almost randomly.
ProppFrexx only touches the ID3 chunk and nothing else - but the errors of mp3 frames are changes all over the file.
Thus, the reasoning must be something different!
How did you create resp. provide the mp3 files for ProppFrexx the first place?
Seems, that you are having a backup - so did you simply copy them over?
Or did you encode them explicitly to mp3 at that time?
Have you checked your hard disk for defects?
And where are they stored, on a local hard disk, a network drive etc.?
In the end I am afraid I can only give some guidance here, but not finally solve the issue, as it doesn't seem ProppFrexx related.