BMediaTrack()::ReadFrames() polluted after Seeking MP3
|Reported by:||ttcoder||Owned by:||nobody|
|Component:||Audio & Video/Codecs||Version:||R1/Development|
|Has a Patch:||no||Platform:||x86|
See attached sample. Here's an outline of what it does:
- dump bytes
- SeekToTime( time 0 ) (SeekToFrame() also triggers the bug)
- dump bytes : they are badly corrupted ! (not at all like those returned by a "fresh" BMediaTrack)
It seems the 'corruption' is not quite random, the buffer seems to be filled with average values (old buffer + new buffer / 2). For instance if you read only one buffer's worth of data (instead of 22 as in my sample) and the data is 0x0 through and through, doing a Seek and then ReadFrames() again will still return a buffer filled with 0x0's as it should. But if you went farther along in the audio file and your last read buffer had high volume samples, seeking back to the (silent) beginning of the file will no longer yield 0x0s but medium'ish samples instead.
Workaround 1 is to discard the BMediaFile object and re-instantiate it before seeking (too expensive).
Workaround 2 is to keep the BMediaFile and BMediaTrack, but throw away the contents returned by the first 2 ReadFrames() calls as it seems they are the only ones "polluted".... Not a great solution, would love to see ReadFrames() be fixed to start with :-)
Change History (13)
comment:4 by , 4 years ago
|Component:||Kits/Media Kit → Audio & Video/Codecs|
|Summary:||BMediaTrack()::ReadFrames() polluted after Seeking → BMediaTrack()::ReadFrames() polluted after Seeking MP3|