Poor resampling quality in SHOUTcast stream

[mjbrown]

Does the SHOUTcast DSP for Winamp do its own resampling, or does the encoder do it, or does Winamp, or what?

The reason I ask is because when listening to my stream, I noticed that when a file with a 48 KHz sample rate was being fed to the DSP, the resulting 44.1 KHz AAC stream had aliasing, the kind that's a symptom of low-quality sample rate conversion. The file normally plays without such aliasing. It's only after going through the SHOUTcast DSP that it's jacked up.

I poked around but couldn't find anything for adjusting the sample rate conversion quality. Maybe I missed something, though.

[DrO]

it most likely is the Source DSP doing things to force it down to 16-bit 44.1KHz PCM and / or what the AAC encoder plug-in is then doing with the converted samples. i know there is some re-sampling code in place though how well it works or not i don't know (never messed with it) so yes probably there is something not right with it, though if so then this is code which goes all the way back to the early v1 DSP days. whether i / whoever will ever look into checking and trying to improve it i cannot say but have made a note of this.

-daz

[mjbrown]

OK, thanks. I will see if I can make some test files for you.

[mjbrown]

Test clips (actual music) to demonstrate the problem are here (click).

We can also see the effect in spectrograms using a simple sine wave sweep.

Here's the test sweep used for the sample rate converter comparisons at src.infinitewave.ca, after it goes through SHOUTcast at 256 kbps AAC:



MP3 looks about the same. The "holes" in the upper left are normal artifacts of AAC encoding and aren't audible; the issue of concern is the fact that the entire spectrum is filled with aliasing "echoes" which certainly are audible, as you can hear in the clips.

After going through SHOUTcast, it really should look more like this:



That's using SoX to do the sample rate and stereo conversion (rate 44100 channels 2), and then playing the resulting 16-bit 44.1 KHz file through the SHOUTcast DSP with the same AAC settings. Although not perfect, there are no audible problems.

The ideal looks more like this:



That's the graph of the SoX-converted file without running it through SHOUTcast. However, when subjected to lossy encoding, it's probably more reasonable to expect output more like the previous graph.

[DrO]

i've got copies of the files you pm'd and already made a note of this thread (the images help btw) but as i'm not actively working on the tools i've no idea on when the issue will be looked into. just thought best to acknowledge this whilst i remember. though what is being used seems to be one of the original parts of the Source DSP's code so is not surprising it's having issues with 48Khz input when that was far from the norm a decade ago.

-daz

[mjbrown]

Yes, I just wanted to post it for whoever looks into improving the sample rate conversion code in the future, or for others who are noticing the sound issues and wondering what's going on.

[rdoctor]

FYI... I was having a similar issue using either 48 kHz MPEG or 48 kHz AAC streams using an Oddcast DSP encoder when monitored through Winamp. After about eight hours of operation, the stream would become audibly distorted and the Winamp red light would start flashing sporadically, sometimes going to solid red. Eventually, the stream stopped playing, but could be resumed by restarting Winamp.

[thinktink]

On the fly re-sampling, even the good ones, depending on the length of the file can sometimes throw off the timing because the resulting number of samples can be a little shorter or longer (relative to the new sample rate) than what is reported (and received by the output plugin.) That can't be realistically avoided. The real solution is to re-sample the audio to what is being (or an even multiple of) expected by the SC DSP and would also avoid most (if not all) of the distortion by the built-in re-sampler of the SC DSP since it's already re-sampled.

[DrO]

my initial thoughts (without doing any coding) were to see what happens if the re-sampling code in the Source DSP is just ignored and we just feed the encoders with the appropriate information as we're getting from ModifySamples(..).

since LAME to my knowledge re-samples anyway as needed and i believe the AAC encoder being used has the same support as well since we're telling them a specific output format to use as well as information about the input format - so would just require the input format being more dynamically updated rather than being fixed (as it currently does).


the other idea was to poach other re-sampling code from the rest of Winamp (which i know has been worked on after the Source DSP's version) and see what difference that makes.


of the 2, the first would be my preferred option to look at doing as yes there's still going to be re-sampling going on but it's only happening once rather than via the two-stages which can typically happen at the moment.

-daz

[mjbrown]

I've been adding a lot more material at non-44.1 KHz sample rates to my streaming library, and the resulting resampling noise is making my stream sound pretty gnarly at times.

Have you experimented with your proposed solutions yet? I'd be happy to help test.

[DrO]

nope and I'm unlikely to look into it now.

[mjbrown]

Great news! All along, there was a workaround: pbelkner's in_ffsox, a.k.a. FFSoX Player. This input plug-in reads pretty much any type of audio (or video) file you want, and it can use SoX to convert the sample rate with high quality, producing whatever the SHOUTcast DSP needs.

I owe a huge thanks to pbelkner for his patience and willingness to help me get it working, especially after I kept prodding him to fix some issues with the title formatting, which mainly affect people who are not using Advanced Title Formatting. These fixes will hopefully be in the next release of the plug-in.

Here are some detailed instructions for those who need them:

1. Close Winamp and run the FFSoX Player plug-in installer. This will put in_ffsox.dll in your Winamp plugins folder, along with an in_ffsox folder which contains SoX, FFmpeg, and other supporting libraries.

Don't start Winamp yet.

2. Decide what audio file types you want in_ffsox to handle. At the very least, you want it to handle the file types that you expect to sometimes need resampling. FFmpeg can handle all the common formats except Windows Media, so to keep it simple, I suggest using it for every type of file you expect to have in your playlist except WMA. For me, that's FLAC, M4A (AAC in MP4 container), MP3, MP2, and Ogg Vorbis. Just in case, I'll also plan to use it for AIFF, APE, WV, and raw AAC, if I ever have any such files.

3. In the plugins folder, disable the extensions that normally handle those file types. This may not strictly be necessary, but it will ensure there are no conflicts. I prefer disabling them instead of uninstalling them through Winamp, so they won't be deleted, in case something goes wrong and you want to re-enable them.

To disable them, just rename them to have something other than a .dll extension. In my case, there are four files to rename:

• in_flac.dll → in_flac.dll.DISABLED
• in_mp3.dll → in_mp3.dll.DISABLED
• in_mp4.dll → in_mp4.dll.DISABLED
• in_wave.dll → in_wave.dll.DISABLED

(If you're doing this through Windows Explorer, you will need to have already disabled "Hide extensions for known file types" in the Folder Options.)

4. The plug-in ships with minimal FFmpeg libraries that don't support all formats (exactly which ones are supported, I don't know; why isn't this documented?).

Based on a comment earlier in this thread, in order read MP3 and some of the other formats, you probably need to replace the DLLs with more robust versions. There's a link to the 32-bit Zeranoe builds on the FFSox Player homepage; follow the instructions to replace the relevant DLLs in the in_ffsox folder.

5. Start Winamp. Go to Preferences > Plug-ins > Input, and go into the FFSoX Player configuration.

In the General tab, make the Extensions list match the file types you decided upon in step 2. In my case, it's

code:
WAV;AIFF;AIF;FLAC;APE;WV;AAC;M4A;MP4;MP3;MP2;MP1;OGG;

In the Audio tab, in the SoX section, set the following:

Mode: Automatic
Sample Rate: 44100 Hz Very High □ Minimum □ Multiple

It's important to make sure Minimum and Multiple are unchecked.

That should be all you need, although I recommend also disabling ReplayGain in the plug-in, so that Winamp's ReplayGain will still be used.

6. Make sure it's working. Load your playlist, go to a file with a non-44.1 KHz sample rate, and look at the File Info (Alt+3). You should see something like this, if it's a 48 KHz MP3:

Decoder: FFmpeg
Length: 2:14
Audio codec: mp3float
Bitrate: 192 kb/s
Bits per Sample (in): 32
Sample Rate (in): 48000 Hz
Bits per Sample (out): 16
Sample Rate (out): 44100 Hz

Look for the text in bold. If it doesn't say FFmpeg, then a different input plug-in is handling the file. If it does say FFmpeg, then it will show the output sample rate, which should be 44100. This is what becomes the input to the SHOUTcast DSP.

That's it! Your stream should sound great, with no more "fuzzy" sound from the bad resampling.

[pbelkner]

Originally Posted by mjbrown

4. The plug-in ships with minimal FFmpeg libraries that don't support all formats (exactly which ones are supported, I don't know; why isn't this documented?).

From the Makefile:

code:
# decoders

FFMPEG_OPTS+=--enable-decoder=pcm_s16le

FFMPEG_OPTS+=--enable-decoder=pcm_s24le

FFMPEG_OPTS+=--enable-decoder=pcm_dvd

FFMPEG_OPTS+=--enable-decoder=flac

FFMPEG_OPTS+=--enable-decoder=wavpack

FFMPEG_OPTS+=--enable-decoder=vorbis

FFMPEG_OPTS+=--enable-decoder=libopus

FFMPEG_OPTS+=--enable-decoder=vp8

# demuxers

FFMPEG_OPTS+=--enable-demuxer=pcm_s16le

FFMPEG_OPTS+=--enable-demuxer=pcm_s24le

FFMPEG_OPTS+=--enable-demuxer=flac

FFMPEG_OPTS+=--enable-demuxer=wav

FFMPEG_OPTS+=--enable-demuxer=ogg

FFMPEG_OPTS+=--enable-demuxer=matroska