[Ed999]

Originally Posted by j_cool

one humble line from your post caught my eye, .mp2 extension trick to squeeze one extra bit of sound quality.

ffmpeg -v 16 -stats -i %url% output.mp2

Do you listen to music on http://www.shoutcast.com ?

vlc.exe http://104.236.206.12:9302/stream

start "Praise Radio" streamripper.exe http://104.236.206.12:9302/stream -d C:\ -o never -u WinampMPEG/5.66

Default appears to be .mp3 128 kb/s for streamripper.

With ffmpeg I get .mp2 384 kb/s.

Good side of streamripper is that it tags .mp3's with names and saves them one by one rather than
one continuous file like ffmpeg.

Do you have an idea how can we get the same outcome with ffmpeg or 384 kb/s files with streamripper ?

http://streamripper.sourceforge.net/tutorialconsole.php

I recently spent a lot more time researching exactly what ffmpeg does, but although I updated some forums where I post, I must apologise for not having updated this thread.

I misunderstood some information about ffmpeg which I found on-line. Although what I posted here was posted in good faith, nevertheless it turned out to be wrong in an important respect. A lot of testing has convinced me that the only effect which specifying .mp2 as the file extension has, is to cause ffmpeg to give special treatment to the input stream it receives.

Note that ffmpeg is called that because it was designed originally to process mpeg streams only. When it receives input as an mpeg stream, which is what an .mp2 stream is, some default behaviour occurs. But the mp2 extension seems to be the only one which still has the behaviour in question. The more popular mp3 format seems to now have its own unique behaviour - so even though it too is an mpeg stream, if you specify mp3 as the output file's extension then ffmpeg exhibits quite different behaviour, not at all what it does with mp2 output.

With mp2 as the output format, recent builds of ffmpeg will save the stream to disk at a 384 kbps bitrate regardless of the bitrate of the incoming stream. Even a 64 kbps stream is automatically saved as a 384 kbps file. The ffmpeg developer apparently believes that the mp2 codec is of such poor quality that saving the stream at less than 320 kbps is pointless. This is a rubbish argument, since I have recordings at 80 kbps using mp2 that are, at least for speech, every bit as good as mp3 at that bitrate.

The 320 kbps streams I was using for testing in my original research were too similar to 384 kbps, so I didn't grasp what was actually happening. And mp2 is not a very common format to run across in a non-video stream. It only became clear to me when I had a 64 kbps mp2 stream to test. Sorry.

Obviously, you can't improve a stream just by saving it to disk at a higher bitrate. The 384 kbps output will fully preserve the sound quality of an mp2 stream, whether it's a 64 kbps input or a 320 kbps input. But there is a slight waste of disk space in doing so (quite a big waste of space if the input was only 64 kbps).

But that's what ffmpeg is doing: if you measure the incoming bitrate of a stream, by playing it in Winamp or in VLC player, you'll see its actual bitrate reported correctly. But try and save it using ffmpeg - as an mp2 file - and it will be saved at an artificially high rate.

Yes, I do listen to SHOUTcast. Yes, I can confirm that if you specify mp2 as the output format, ffmpeg will convert the input stream, even a stream (such as on SHOUTcast) that is not an mp2 stream, and save it to disk at 384 kbps even though it's only a 128 kbps stream. It's a really unhelpful feature of ffmpeg.

For SHOUTcast, streamripper is far and away a better choice than ffmpeg. No possibility at all of streamripper (or stationripper) monkeying with the stream, because streamripper has no ability to modify the bitrate or sample rate of the input.



.