FFSoX Player 0.1 Initial Release Options

[greynol]

AFAICT none of those preferences have any bearing on audible sound quality that you will be able to demonstrate through objective means. Prove that I'm wrong.

This post has been edited by greynol: Dec 15 2012, 16:28

[greynol]

By the way: do you recommend the use of the steep filter option? and why?

Don't hold your breath waiting for a tangibly meaningful answer to this second question.

[Wombat]

Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.

[pbelkner]

Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.

That's a perfect example of a Straw man: Besides the argument may be true w.r.t. to the automatic dithering feature of the SoX command line tool, it is not true w.r.t to the FFSoX plug-in. If the respective check box is checked the dithering effect is added to the effects chain, otherwise not (regardless whether this is useful or not). There's no automatic dithering in FFSoX.

Edit: If the emphasis is on "noise shaped" than the argument seems to be valid. The following is from SoX's "dither.c":

CODE

static const filter_t filters[] = {
  {44100, fir,  5, 210, lip44, Shape_lipshitz},
  {46000, fir,  9, 276, fwe44, Shape_f_weighted},
  {46000, fir,  9, 160, mew44, Shape_modified_e_weighted},
  {46000, fir,  9, 321, iew44, Shape_improved_e_weighted},
  {48000, iir,  4, 220, ges48, Shape_gesemann},
  {44100, iir,  4, 230, ges44, Shape_gesemann},
  {48000, fir, 16, 301, shi48, Shape_shibata},
  {44100, fir, 20, 333, shi44, Shape_shibata},
  {37800, fir, 16, 240, shi38, Shape_shibata},
  {32000, fir, 20, 240/*TBD*/, shi32, Shape_shibata},
  {22050, fir, 20, 240/*TBD*/, shi22, Shape_shibata},
  {16000, fir, 20, 240/*TBD*/, shi16, Shape_shibata},
  {11025, fir, 20, 240/*TBD*/, shi11, Shape_shibata},
  { 8000, fir, 20, 240/*TBD*/, shi08, Shape_shibata},
  {48000, fir, 16, 250, shl48, Shape_low_shibata},
  {44100, fir, 15, 250, shl44, Shape_low_shibata},
  {44100, fir, 20, 383, shh44, Shape_high_shibata},
  {    0, fir,  0,   0,  NULL, Shape_none},
};

If a particular sample rate doesn't fit into the map the request for noise shaping is ignored:

CODE

for (f = filters; f->len && (f->name != p->filter_name || fabs(effp->in_signal.rate - f->rate) / f->rate > .05); ++f); /* 5% leeway on frequency */
if (!f->len) {
  p->alt_tpdf |= effp->in_signal.rate >= 22050;
  if (!effp->flow)
    lsx_warn("no `%s' filter is available for rate %g; using %s TPDF",
        lsx_find_enum_value(p->filter_name, filter_names)->text,
        effp->in_signal.rate, p->alt_tpdf? "sloped" : "plain");
}

This post has been edited by pbelkner: Dec 15 2012, 19:56

[bandpass]

AFAICT none of those preferences have any bearing on audible sound quality that you will be able to demonstrate through objective means. Prove that I'm wrong.

Steep filter here gives 99% instead of 95% passband, so compare (on unix):

play -r 16k -n synth 4 sin 7920 rate 48k
play -r 16k -n synth 4 sin 7920 rate -s 48k

Difference is night and day. Though with a typical ADC instead of a synth'd signal, there's probably no useful (unaliased) content that high up.

[greynol]

I didn't think qualifications against synthesized signals would be necessary. I suppose I should also mention that I'm not interested in cranking the volume on fade-outs too.

[Wombat]

Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.

That's a perfect example of a Straw man: Besides the argument may be true w.r.t. to the automatic dithering feature of the SoX command line tool, it is not true w.r.t to the FFSoX plug-in. If the respective check box is checked the dithering effect is added to the effects chain, otherwise not (regardless whether this is useful or not). There's no automatic dithering in FFSoX.

Edit: If the pronunciation is on "noise shaped" than the argument seems to be valid. The following is from SoX's "dither.c":

Straw man? Pronunciation? Huh?

[pbelkner]

Pronunciation? Huh?

Many thanks for the hint. I've corrected it.

[Wombat]

Still i feel insulted by your Straw Man argument. You are the person explicitly recommending 192kHz upsampling with emphasis on Noise Shaping while sox doesn´t.

[pbelkner]

You are the person explicitly recommending 192kHz up-sampling with emphasis on Noise Shaping while sox doesn't.

1. Put into general terms, the recommendation is to set the sample rate to the maximum sample rate supported by the DAC. Any other setting makes no sense because in such a case we can assume the DAC to up-sample a second time. My DAC supports 192 kHz, hence the preference.
2. AFAIK there are still a lot of DACs out there supporting just 48 kHz. In such a case it perfectly makes sense to choose the "noise shaping" option. For a general recommendation I see no need to dive into a discussion on whether SoX is supporting that option for a particular sample rate or not, because in case it is not supported it is simply ignored.

[[JAZ]]

@pbelkner: To put it on perspective, i'll give my point of view of in_ffsox before comenting on these last posts.

When you announced in_ffsox, I didn't see the need for it at all (most, if not all of the formats that the plugin provided, were already supported, and there wasn't a reason to think that the quality was suffering). The part about resampling could be and addition, (because a resampler as a DSP in winamp is problematic), but not a "must have" feature.

Now, onto the real subject:

The necessity of having a resampler between the source format, and the soundcard happens only when the soundcard (or its drivers) apply a bad quality one, and only then, if you can provide a better one. Since you're talking about soundcards supporting 192Khz, the question arises by itself.

It also makes me wonder the usage of a steeper filter cutoff than the default. The origin of higher sampling rates, and especifically, of upsampling DACs was precisely the ability to use a softer cutoff (easier to implement, and less ripple).

Now, dithering and noise shaping.
Dithering applies to bit depth, and noise shaping is dependant on sample rate. Using dithering at 24bits for playback is one of those things that can directly be considered nonsense. No hardware is able to play 24bits, so how can the last bit truncation matter? Sometimes it has been said (see wiki) that even dithering at 16bits is unneeded when the source is noisy, like a tape recording.

So if dithering is not necessary (like I'm saying above), shaping the result doesn't matter. It's true that being a high sample rate, it can shift most of the noise outside of the audible range (higher frequency), but in practice, it already is (below the noise floor).

This post has been edited by [JAZ]: Dec 15 2012, 23:31

[pbelkner]

When you announced in_ffsox, I didn't see the need for it at all (most, if not all of the formats that the plugin provided, were already supported

This may be true for audio formats but by no means this is true for video formats. I'm not aware of any other player supporting ReplayGain for video formats. To me, RG for video formats is the outstanding feature of "in_ffsox" and the lack of it in existing players was the initial driving force for developing the plug-in.

This post has been edited by pbelkner: Dec 16 2012, 04:43

[bandpass]

I didn't think qualifications against synthesized signals would be necessary.

The synth'd signal is just a sine wave—it could have been captured using an ADC with a steep filter.

[[JAZ]]

Ok, I didn't think about it.
How is the replaygain calculated, and how is it stored? (Directly from Winamp? I ask because i didn't saw it in the plugin's sourceforge page, and i could only find a tool called ffmpeg-replaygain, not updated in two years)

On the other hand, the wording in the "Objectives" section (and part of others) in that page wouldn't probably pass HydrogenAudio's standards.
(Also note that I would use winamp kernel streaming plugin, if the soundcard needs ASIO4ALL to have ASIO capabilities).

[pbelkner]

How is the replaygain calculated, and how is it stored? (Directly from Winamp? I ask because i didn't saw it in the plugin's sourceforge page, and i could only find a tool called ffmpeg-replaygain, not updated in two years)

You may use "r128gain" (it's mentioned on top of the SF page).

Only a few video formats can store RG tags, e.g. FLV and MKV. For the others, e.g. VOB, AVI, MP4, you should use the MKV format option from "r128gain". This will wrap the video and audio streams taken from the input into a RG tagged MKV container you may playback with "in_ffsox".

[greynol]

The synth'd signal is just a sine wave—it could have been captured using an ADC with a steep filter.

Synthesized...as opposed to an actual piece of music.

Either way, thanks for providing something the author seems either unwilling or unable to do. So based on your expertise on the matter, are his veiled claims of audible superiority justified?

This post has been edited by greynol: Dec 16 2012, 17:13

[bandpass]

If source and destination rates are both >= 44100, then SoX's default transition-band preserves the entire audio band (i.e. to 20kHz), so there's no benefit in a steeper filter. If at least one of the rates is < 44100, then the default transition-band lies at least partly within the audio band. If your ADC (or DAC or both) used with this audio has a steep filter, then you might as well preserve the extra bandwidth this gives by using a steep resampling filter. I wouldn't be surprised if some people could ABX the difference this gives, on some music.

However, are ADCs/DACs with steep filters and at < 44100Hz sample-rate much used in practice? Not as far as I know. E.g. the AES (and ITU) recommendation for "high quality" (as opposed to "studio quality") audio is sampled at 32kHz but the nominal passband is 15kHz (I assume 3dB point) so audio captured according to this spec. and subsequently upsampled would not require a steep filter.

[smeekeven]

Hi Peter Belkner,

You know I'm a dedicated user of your plugin, I love it.
With this month additions of the zeranoe ffmpeg daily builds things are broken ....
The stuttering sounds happen all over the playlist: MP3, MPC and APE are all affected.
Only FLAC seems to decode properly.
Can you please take a look at this?

Thanks!

[smeekeven]

Problems with decoding MP3, APE and MPC files since version 0.4.9.5

Happy Newyear!
I just found out that the new Zeranoe ffmpeg builds (latest from 20130103) are ok with in_ffsox up to version 0.4.9.4
All file formats (i.e. FLAC, MP3 but also APE and MPC) are decoding perfectly normal.
Since version 0.4.9.5 up to 0.6.1 there are errors ("stuttering") with APE and MPC and even MP3's

Hope this can be resolved in the next build of in_ffsox

Thanks in advance!

[pbelkner]

Happy Newyear!

Happy new year too!

Since version 0.4.9.5 up to 0.6.1 there are errors ("stuttering") with APE and MPC and even MP3's

Unfortunately I'm not able to reproduce this. But I've changed something with the planar representation anyway and have uploaded a new version. Hope this helps.

http://sourceforge.net/projects/in-ffsox/f...x/in_ffsox-0.6/

[smeekeven]

in_ffsox-0.6.2-ffmpeg works perfectly !


PBelkner did a great job by releasing a major update of the in_ffsox plugin.

His tweaking of the planar representation makes that all audio formats can be played flawlessly through the ffmpeg filters.
There is no more "stuttering" noise that was obvious when decoding mp3, mpc, ape, wv and shn files in versions prior to this release.

I use ffmpeg daily builds from Zeranoe in combination with FFSoX Player for Winamp to play all my music files
(AAC;AIF;AIFF;APE;FLAC;M4A;M4P;MP3;MPC;OGG;SHN;WAV;WMA;WV)

ffmpeg builds can be found at:
http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D

Just copy the avcodec-54.dll, avformat-54.dll, avutil-52.dll and swscale-2.dll over the existing ones in
\winamp\plugins\in_ffsox directory

Cheers!

[smeekeven]

New avcodec-55.dll and avformat-55.dll Zeranoe builds

Hi Peter,
avcodec-55.dll and avformat-55.dll are updated versions of avcodec-54.dll and avformat-54.dll and new in
ffmpeg-20130314-git-9efcfbe-win32-shared Zeranoe daily builds of ffmpeg
http://ffmpeg.zeranoe.com/builds/win32/shared/?C=M;O=D

Can you please adapt the ffsox player plugin to work with this new versions?

Thanks in advance.
Greetings,
Smeekeven.

[pbelkner]

New avcodec-55.dll and avformat-55.dll Zeranoe builds

Can you please adapt the ffsox player plugin to work with this new versions?

I've uploaded in_ffsox-0.6.3.

Thank you for your support.

Regards, Peter