This project has moved and is read-only. For the latest updates, please go here.

InvalidOperationException on playing some MP3 files

Oct 30, 2012 at 3:50 PM

I keep getting an exception with the message "Got a frame at sample rate 44100, in an MP3 with sample rate 48000. Mp3FileReader does not support sample rate changes." when playing some MP3 files. Is there anything else I can use to play MP3 files? Thanks in advance. I'm using version 1.6 of NAudio.

Oct 31, 2012 at 2:53 PM

I put that exception in to show that the MP3 is not playable by NAudio. The only options when you get a sample rate change in NAudio are to close your WaveOut device and open another at the new sample rate, or to put a resampler in your audio pipeline. I'm hoping that NAudio 1.7 will have a WaveFormatChanged event on Mp3FileReader, allowing people to disable this exception and write their own handling logic for format changes. Currently though, you'd have to create your own customised Mp3FileReader to play files like this.

It should be very rare that MP3s contain frames of different sample rates. It is usually a sign someone has tried to concatenate parts of two completely different MP3 files/

Oct 31, 2012 at 5:15 PM

Oh, okay...because I'm playing the sample music in Windows 7. One of them gave me that exception.

Jan 26, 2013 at 5:12 AM
Edited Jan 26, 2013 at 5:13 AM
markheath wrote:

It should be very rare that MP3s contain frames of different sample rates. It is usually a sign someone has tried to concatenate parts of two completely different MP3 files/

I think this is not rarly as you think.  VBR  file is totally common in use, such as  "Sleep away.mp3" in Windows 7. And i have this problem files many times

Would u support this feature one day?


  When you want to read info about an MPEG file, it is usually enough to find the first frame, read its header and assume that the other frames are the same. But this may not be always the case. Variable bitrate MPEG files may use so called bitrate switching, which means that bitrate changes according to the content of each frame.

Jan 26, 2013 at 7:54 AM

You are confusing bitrate and sample rate. NAudio has no problem playing VBR MP3s that have different bitrates in every frame. The trouble is when the sample rate or the channel count changes. If that happens, the decoder will start emitting a different PCM WAV format. If you were playing out the soundcard, you would need to close and re-open the soundcard, or resample and convert the channel count to the same number as the original. Otherwise the audio would speed up or slow down.The same problem occurs if you are converting MP3 to WAV. A WAV file cannot contain sections with different PCM formats, so if different MP3 frames in the same file convert natively to different PCM sample rates or channel counts you have to do a further conversion on the decoded audio.

I do wonder if some VBRs like the one you mention above contain just one frame at a different sample rate, and maybe NAudio could somehow detect this and skip over it.

Jan 27, 2013 at 5:32 AM

Thank you for reply

I got something wrong with CBR VBR.

As you say different frame may have different bit rate but has the same sample rate.

 Is it possible has different sample rate too?

I have sent the strange mp3 file of Windows sample music to your email . Please check it .

Jan 28, 2013 at 4:38 PM

Yes, that particular file has been mentioned to me before. The first two frames are 48kHz, whilst the rest is 44.1kHz. I have no idea why this might be. I thought at first they might be XING or VBRI headers, but they don't appear to be. I have no idea why MS would make a file like this. I've only seen something like it on one other occasion, where a file had one frame at 48kHz, and the rest at 44.1kHz. On that file it was actually album art being mistaken for a valid MP3 frame. A similar thing could be happening here I suppose. There could be a problem with the code that tries to jump over the ID3v2 tag.

Jan 28, 2013 at 8:09 PM

FYI, I looked at the file in question...  The first frame starts 528 bytes after the "official" end of the ID3v2 tag (when seeking from the start using the tag's length field).  If the decoder just skips the tag and doesn't properly validate sync headers, it will sync with some spurious data that "looks like" a Stereo Layer I frame @ 384kbps and 48khz.

That said, if the sync is checked against the following, the spurious data will be properly skipped:

  • Frame Sync (11 set bits)
  • MPEG Version != reserved (01)
  • Layer != reserved (00)
  • Bitrate != invalid (1111)
  • Sample Rate != reserved (11)
  • Channel Mode Extension == 00 - or - Channel Mode == Joint Stereo

I believe the channel mode extension check is what is lacking...

Jan 28, 2013 at 8:32 PM

thanks ioctlLR, I'll revisit the code, I know I check a few of those things, but maybe one is missing.

Jan 29, 2013 at 11:55 AM

brilliant, the channel mode check fixes the "Sleep Away" MP3, and I've checked the fix in. Unfortunately it does not fix the other two example files I have. I wonder if there is a problem with my jumping over the ID3v2 tag not properly calculating its length.

Mar 22, 2013 at 2:38 PM
Hi, I have this issue with a large number of my audio files (about 50% of them). How would I make my program check for this issue before I try to run the sound file?
Mar 22, 2013 at 4:41 PM
Half your files? What are you making them with? Are you able to link to an example that doesn't play in NAudio? I have a collection of problem MP3 files, but most of them are now working
Mar 25, 2013 at 2:18 PM
Here's a couple of them:

I unfortunately do not remember what program was used. I got them from a friend years ago.
Mar 25, 2013 at 8:29 PM
Thanks for these. I've seen instances where the album art can get misinterpreted as a valid mp3 header. I'm not sure how to work around this. There might be some deeper checking within the MP3 frame payload, but that would require more knowledge than NAudio currently has of the inner workings of MP3. I'll keep hold of the files in the hopes that one day I'll find a good way to deal with this issue.
Jul 17, 2014 at 1:54 PM
I have lots of downloaded mp3 files with exactly same samplerate problem. It's ok not to play those files, but my player crashes every time. How can I handle this error correctly?

I have following code to load mp3 file:
public void LoadTrack(string file)
    if (waveOutDevice == null)
        waveOutDevice = new WaveOutEvent()
            DesiredLatency = 200,
            NumberOfBuffers = 2

        audioFileReader = new AudioFileReader(file);

        var postVolumeMeter = new MeteringSampleProvider(audioFileReader);
        postVolumeMeter.StreamVolume += OnPostVolumeMeter;

        audioFileReader.Volume = audioVolume;
Error is happening while initializing audioFileReader. If I put all this code to try block, and do nothing about it in catch block, there's no crash - yet. Next error comes when I try to close that file and play new one. waveOutDevice.Dispose() generates NullReferenceException, even if code checks that it's not null before disposing.
public void CloseTrack()
    if (audioFileReader != null)
        audioFileReader = null;

    if (waveOutDevice != null)
        waveOutDevice = null;
How can I keep my player stable after this samplerate error?

Jul 17, 2014 at 3:25 PM
the null reference on dispose is a known bug with WaveOutEvent if you dispose without having successfully initialized. Will be fixed in the next release (1.7.2 coming to NuGet soon hopefully).