This project has moved. For the latest updates, please go here.

Mp3FileReader does not support sample rate changes.

Jun 25, 2013 at 9:38 AM
Hi Mark,

When I was trying to read a mp3 file using NAudio, I got this error.
Got a frame at sample rate 44100, in an MP3 with sample rate 48000. Mp3FileReader does not support sample rate changes.
Then what method should be used to read this kind of mp3 files?

Thanks
Jun 25, 2013 at 12:11 PM
Savinda,

The simplest way to do it (and I use the term "simplest" loosely) is to implement your own MPEG stream reader (the part that reads the raw frames out of the file) and pass the frames to Mp3FrameDecompressor as you need them decoded. That way you can catch sample rate changes as you go.

Please note: If you are outputting the decoded data in any way, you'll need to resample the frames that are not at the same rate as the file. There are plenty of ways to do it, but you might consider using a ResamplerDmoStream.
Coordinator
Jun 25, 2013 at 12:19 PM
Sample rate changes ought not to occur in most MP3 files. I think the most common cause of this problem is NAudio accidentally interpreting the album art as an MP3 frame (in this case as a 48kHz frame), and then the first real frame comes along and it has a different sample rate. I've tried several times to fix this, but with only partial success. I do try to skip over the ID3V2 tags and I have reviewed the code several times, but I can't see anything wrong with it.

An alternative solution you can use if this is your problem is the MediaFoundationReader I've added for NAudio 1.7 (currently in alpha). It should be better at detecting the first real MP3 frame.
Oct 14, 2013 at 1:54 PM
What does the sample rate change actually affect?

We have to grab the raw data from each MP3 frame for hashing in our application, and we have a test from (presumably an old edge case in our catalogue) that has two sets of id3 tags at the end of the track. This test track worked fine in NAudio 1.3.10, but I just tried upgrading to 1.6 and we get the above exception for it. If I comment out the throw inside Mp3FileReader.cs our code still works fine though.

So is the sample rate change a horrible thing? Would you be opposed to a patch that allows clients to disable the check?

I can't seem to work around it any other way. Great library, BTW. We've been using it for years with very few issues!

Thanks!
Coordinator
Oct 14, 2013 at 1:58 PM
it affects playback - you'd be playing sound at the wrong sample rate which would sound wrong. What is usually happening though is that there is some data at the start of the MP3 file (maybe album art?) that is being interpreted incorrectly as a frame. If you try with the very latest code, this issue will hopefully be resolved for all MP3s that don't actually have a sample rate change in them.
Oct 14, 2013 at 2:21 PM
Thanks for the reply.

I think in this situation it's from the doubled up tags at the end of the track rather than a sample rate change (the track sounds fine). I've tried with the current master branch too and the problem is still there (ie failing the rate comparison and throwing the above exception).
Oct 14, 2013 at 2:22 PM
In fact it's one of the last frames of the file that throws this - it's fine for the rest of it.
Coordinator
Oct 25, 2013 at 10:56 AM
hmmm, not sure what is causing this. I'd need an example MP3 file. If you are able to use MediaFoundationReader when NAudio 1.7 comes out then that might be a good idea.
Nov 20, 2013 at 6:20 PM
FYI, I was having the same issue with Mp3FileReader ("Mp3FileReader does not support sample rate changes") on some of my mp3 files, switched over to using MediaFoundationReader as Mark suggested, resolved my issues! Thanks Mark!
Coordinator
Nov 20, 2013 at 9:32 PM
yes, MediaFoundationReader is a good solution if you can use it. I have tried so many times to fix this issue, and thought I had finally done so in NAudio 1.7 but obviously not. Basically, NAudio is getting some false positives where it thinks its found an MP3 frame which actually isn;t one. I've read and re-read the MP3Frame header spec to try to find anything that might help eliminate these false positives but haven;t found anything yet. Might actually need to parse out the contents of the frame as well to get better accuracy.
Dec 3, 2014 at 8:34 PM
I also encountered this problem with the latest NAudio library when running Mp3FileReader against a bunch of "sliced and diced" MP3 files. These files have partial MP3 frames at the beginning of the file which seems to be where Mp3FileReader gets into trouble.

I was able to write a "MP3 Frame Walker" method that only picks up valid MP3 frames (C# source code is avail if you want it). The strategy that I used was to do a byte-by-byte search for a valid MP3 frame header (same as Mp3FileReader) but before declaring the frame header valid, attempt to decode the next N frame headers. As a bonus, this technique removes the need to pay any attention whatsoever to the ID3V1 or ID3V2 tags.

I wrote the code to allow for a variable probe depth but a probe depth of 1 parsed all my "problem files" correctly.
Coordinator
Jan 9, 2015 at 10:34 PM
Yes, I think I'll eventually have to move to this approach. I'm leaning towards encouraging people just to use MediaFoundationReader these days, since it's only Windows XP in which you can't use it.