Problems with handling finishing the playback

Apr 26, 2009 at 9:32 PM
Edited Apr 27, 2009 at 10:54 AM
first thanks for providing such great software for .NET to play WAV and MP3.

However I'm having troubles with handling the playback finished (meaning by that that the input stream reached its end). I'm playing MP3 from file - constant bit rate 128 kbps, using WaveOut and I noticed playbackStopped event will not handle when the stream reaches its end (the OnDone method has a byte array full of zeroes, however it is expecting from the method Read to return 0. So I tried adding to the WaveStream Read method that if (Position >= Length) return 0; The event was signalled, but even sooner that the playback truly finished (I noticed the MP3 length is 4:34, while the real MP3 length is 4:39, put playing it is flawless. At 4:34 the Position = Length in the MP3FileReader.). Any suggestion why that might be happening?

I added the Position >= Length thing to the wrong stream. However I noticed that in WaveChannel32.cs in method Read there is a bug with PaddingWithZeroes. The buffer was padded with zeroes even if the the read from the source stream returned zero and the return value was the length of the array. So by adding a check to return a zero when the SourceStream read method returns 0 I resolved the issue and the StoppedCallback is now properly called when the playing truly finishes.
May 14, 2009 at 5:48 PM

Hi there,

The length determining of MP3 files is not particularly good, as it may be VBR, in which case it cannot be determined. The solution you have come up with is the right approach though.


Jun 18, 2009 at 7:18 AM


I've built a waveform visualization around NAudio, but I'm being bitten badly by the MP3 length issue. I find that when I open an MP3 file, the length is a couple of seconds shorter than reported by other audio editors and that as the file plays, it gets out of sync with the waveform. When I open a WAV file, this is not a problem.

I understand that determining the MP3 length without scanning the whole file makes it hard to predict the length, but isn't there some way that one can determine the actual length? Even if it means scanning the whole file?



Jun 18, 2009 at 11:24 AM

Yes, it should be possible to determine the length if you read the entire file. You could even generate a map of positions in the file to timestamps to aid in repositioning later. Its something that would be nice to put into a future version.