mp3Reader CurrentTime advancing 2x too fast???

[cvdevol]

VS2015. Windows Forms. VB.NET. Playing an mp3 with total time of 2:27 as shown by mp3Reader.TotalTime (verified accurate). When the stop event is triggered, the mp3Reader.CurrentTime is shown as exactly twice the TotalTime, i.e. 4:54!!!

This happens similarly for every mp3 file I play.

Note: switched to AudioFileReader instead of mp3Reader and the problem went away.

[markheath]

very strange, haven't seen that myself and not sure why that should happen. If you can create a small unit test that reproduces I'd be interested

[viper3400]

Hi @markheath

Got into this today, too. Using NuGet Package 1.8.1 in my test app (VS Community 2017 15.3.0 Preview 4, C#) and also reproducible with the demo app in current master branch c7d1f54

I've attached two files containing 15 seconds of 2 channel white noise.

• whitenoise.wav (2 channel PCM 16 Bit 44.1kHZ)
• whitenoise.mp3 (2 channel stereo mpeg layer II 128 kBit/s constant bit rate)

whitenoise.zip

• Open the NAudioDemo windows form app
• Load the "Simple Playback" module
• Open the wav file with a total time of 15 seconds
• Press play and see, that that the current time is correct, while playing
• Repeat these steps with the mp3 file
• While total time is still 15 seconds, the current time is running 2 times faster as expected

I've seen this with AudioFileReader and Mp3Reader. This makes no difference for me. Obviously there is a difference between the two audio formats and a problem in calculating the currentTime from Position.

When playing my MP3 files I run into method NAudio.Wave.WaveStream.CurrentTime

return TimeSpan.FromSeconds((double)Position / WaveFormat.AverageBytesPerSecond);

If I would change this to

(double)audioFileReader.Position / audioFileReader.WaveFormat.AverageBytesPerSecond / 2)

the currentTime of the MP3 file would be calculated correct, but than the calculation with the WAV file would fail ... this is not really the point. So I suppose the problem lies deeper, maybe within calculation of Position or the AverageBytesPerSecond. Maybe there is a problem with determine the audio format and therefore the wrong parametes are set?

Would need a deeper dive into it. Don't know how to provide a proper unit test for this from my current view.

[markheath]

worked it out. it was the fix to issue #161 causing us to double up advancing the position