Help - Search - Members - Calendar
Full Version: 32khz mp3 fails
Hydrogenaudio Forums > Hosted Forums > foobar2000 > Support - (fb2k)
tboehrer
Foobar2000 0.8.1b2

Trying to listen to previews on Audio Lunchbox (www.audiolunchbox.com).

I get the following warnings constantly:

INFO (CORE) : opening file for playback :
INFO (CORE) : location: "http://audiolunchbox.com/preview.mp3?i=89511" (0)
INFO (foo_out_dsound_ex) : Created stream: 32000Hz 16bps 2ch
WARNING (foo_input_std) : mpeg stream error at 5910 bytes, attempting resync
INFO (foo_input_std) : mpeg stream resync successful
WARNING (foo_input_std) : mpeg stream error at 14270 bytes, attempting resync
INFO (foo_input_std) : mpeg stream resync successful
WARNING (foo_input_std) : mpeg stream error at 22270 bytes, attempting resync


The previews work fine using WinAmp or WMP9.
Moneo
This probably means that the files are corrupted.

Are there audible glitches when playing back those files, or are you just annoyed by the console popping up all the time? If it is the latter, you can turn it off using the "options..." button in the console window.
tboehrer
QUOTE
This probably means that the files are corrupted.


How could this be true? Both Windows Media Player and Winamp play them just fine. Either of those playback with no glitches.
kjoonlee
If it says "WARNING (foo_input_std) : mpeg stream error at x bytes, attempting resync", then chances are any mpeg stream checker will complain, but if you see "INFO (foo_input_std) : mpeg stream resync successful", then chances are most programs will play them without any warnings.

So I guess the bottom line is: those files are only slightly corrupted.
tboehrer
QUOTE
So I guess the bottom line is: those files are only slightly corrupted.


The notion that these streams are corrupted is just plain silly. Use your heads guys. If 1 out of 3 players fails to play them, the problem is the player.

But I do have more information. I have a program called RipCast which will save the stream to disk. After doing so, Foobar will play the 32khz file just fine. So it has to be something when streaming it.
tboehrer
I believe I know what the problem is:

The "Transfer-Encoding" header returned in the HTTP response is "chunked".

For chunked response, the format is (per RFC 2616):

CODE

3.6.1 Chunked Transfer Coding

  The chunked encoding modifies the body of a message in order to
  transfer it as a series of chunks, each with its own size indicator,
  followed by an OPTIONAL trailer containing entity-header fields. This
  allows dynamically produced content to be transferred along with the
  information necessary for the recipient to verify that it has
  received the full message.

      Chunked-Body   = *chunk
                       last-chunk
                       trailer
                       CRLF

      chunk          = chunk-size [ chunk-extension ] CRLF
                       chunk-data CRLF
      chunk-size     = 1*HEX
      last-chunk     = 1*("0") [ chunk-extension ] CRLF

      chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
      chunk-ext-name = token
      chunk-ext-val  = token | quoted-string
      chunk-data     = chunk-size(OCTET)
      trailer        = *(entity-header CRLF)


This is what I see when capturing the response. That is:

The response starts with 4 bytes specifying the length (in this case 0x16a0) following by CR LF, followed by data (starting with 0xFF 0xFB etc...).

If I jump forward to offset 0x16a6 (4 byte length + CR LF), there is another chunk length + CRLF.

Interesting enough, Winamp uses HTTP 1.0 and doesn't get a chunked response (so it works fine). Media Player uses HTTP 1.1 and handles the chunked response properly.
tboehrer
I imagine this thread is in the wrong forum now...

I change jnetlib to use "HTTP/1.0" instead of "HTTP/1.1", and the streaming from audiolunchbox.com works fine. I tested one other streaming server I use (magnatunes.com), and this "fix" seems to work there too (though magnatunes worked with HTTP/1.1).

So.. It's not for me to decide, but either foo_read_http needs to handle chunked responses (or jnetlib does), or stick with HTTP/1.0. Further evaulation would be required.
tboehrer
I tested the HTTP/1.0 change with several other streaming servers, including some from www.shoutcast.com. They all seemed to work fine. The most horrifying thing I encountered was a 80's Pop station.... crying.gif
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.