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.

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/

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

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?

ref:

  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. 

http://mpgedit.org/mpgedit/mpeg_format/MP3Format.html

http://en.wikipedia.org/wiki/MP3

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.

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 .

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.

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...

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

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.