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.
Full Version: 32khz mp3 fails
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.
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.
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.
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.
So I guess the bottom line is: those files are only slightly corrupted.
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.
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):
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.
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.
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.
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.
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.... 
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.