IPB

Welcome Guest ( Log In | Register )

4 Pages V  « < 2 3 4  
Reply to this topicStart new topic
FFSoX Player 0.1 Initial Release
greynol
post Dec 15 2012, 15:46
Post #76





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Dec 15 2012, 15:56
Post #77





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (smeekeven @ Dec 14 2012, 02:39) *
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. wink.gif


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Wombat
post Dec 15 2012, 16:41
Post #78





Group: Members
Posts: 950
Joined: 7-October 01
Member No.: 235



Besides that sox doesn´t add noise shaped dither to 192kHz material afaik.
Go to the top of the page
+Quote Post
pbelkner
post Dec 15 2012, 18:56
Post #79





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (Wombat @ Dec 15 2012, 17:41) *
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
Go to the top of the page
+Quote Post
bandpass
post Dec 15 2012, 19:16
Post #80





Group: Members
Posts: 321
Joined: 3-August 08
From: UK
Member No.: 56644



QUOTE (greynol @ Dec 15 2012, 14:46) *
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.
Go to the top of the page
+Quote Post
greynol
post Dec 15 2012, 19:39
Post #81





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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. dry.gif


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Wombat
post Dec 15 2012, 19:52
Post #82





Group: Members
Posts: 950
Joined: 7-October 01
Member No.: 235



QUOTE (pbelkner @ Dec 15 2012, 19:56) *
QUOTE (Wombat @ Dec 15 2012, 17:41) *
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?
Go to the top of the page
+Quote Post
pbelkner
post Dec 15 2012, 19:57
Post #83





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (Wombat @ Dec 15 2012, 20:52) *
Pronunciation? Huh?

Many thanks for the hint. I've corrected it.
Go to the top of the page
+Quote Post
Wombat
post Dec 15 2012, 20:11
Post #84





Group: Members
Posts: 950
Joined: 7-October 01
Member No.: 235



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.
Go to the top of the page
+Quote Post
pbelkner
post Dec 15 2012, 20:35
Post #85





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (Wombat @ Dec 15 2012, 21:11) *
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.
Go to the top of the page
+Quote Post
[JAZ]
post Dec 15 2012, 23:27
Post #86





Group: Members
Posts: 1706
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



@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
Go to the top of the page
+Quote Post
pbelkner
post Dec 16 2012, 04:37
Post #87





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE ([JAZ] @ Dec 16 2012, 00:27) *
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
Go to the top of the page
+Quote Post
bandpass
post Dec 16 2012, 10:33
Post #88





Group: Members
Posts: 321
Joined: 3-August 08
From: UK
Member No.: 56644



QUOTE (greynol @ Dec 15 2012, 18:39) *
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.
Go to the top of the page
+Quote Post
[JAZ]
post Dec 16 2012, 11:01
Post #89





Group: Members
Posts: 1706
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



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).

Go to the top of the page
+Quote Post
pbelkner
post Dec 16 2012, 15:38
Post #90





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE ([JAZ] @ Dec 16 2012, 12:01) *
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".
Go to the top of the page
+Quote Post
greynol
post Dec 16 2012, 17:09
Post #91





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (bandpass @ Dec 16 2012, 01:33) *
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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
bandpass
post Dec 16 2012, 22:29
Post #92





Group: Members
Posts: 321
Joined: 3-August 08
From: UK
Member No.: 56644



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.
Go to the top of the page
+Quote Post
smeekeven
post Dec 30 2012, 14:40
Post #93





Group: Members
Posts: 7
Joined: 10-November 12
Member No.: 104444



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!
Go to the top of the page
+Quote Post
smeekeven
post Jan 3 2013, 15:38
Post #94





Group: Members
Posts: 7
Joined: 10-November 12
Member No.: 104444



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!
Go to the top of the page
+Quote Post
pbelkner
post Jan 6 2013, 23:25
Post #95





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (smeekeven @ Jan 3 2013, 16:38) *
Happy Newyear!

Happy new year too!

QUOTE (smeekeven @ Jan 3 2013, 16:38) *
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/
Go to the top of the page
+Quote Post
smeekeven
post Jan 7 2013, 13:24
Post #96





Group: Members
Posts: 7
Joined: 10-November 12
Member No.: 104444



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!
Go to the top of the page
+Quote Post
smeekeven
post Mar 16 2013, 09:53
Post #97





Group: Members
Posts: 7
Joined: 10-November 12
Member No.: 104444



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.
Go to the top of the page
+Quote Post
pbelkner
post Mar 16 2013, 11:44
Post #98





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (smeekeven @ Mar 16 2013, 10:53) *
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
Go to the top of the page
+Quote Post
mjb2006
post Dec 8 2013, 06:29
Post #99





Group: Members
Posts: 706
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



Peter did end up toning down the docs to just say what the plug-in does and how to configure it. I think that's for the best, but if anything, it's a little too terse now; you have to infer what most of the features are by looking at the configuration info. Here is what I would say about it, if I were the developer:

FFSoX Player is an input plug-in for Winamp that supports reading audio & video files. It tailors the audio to specific characteristics (bit depth, sample rate, dither, and volume level), for the potential benefit of the rest of the output chain (i.e., the DSP plug-ins, the output plug-in, Windows audio APIs, and your audio hardware). The plug-in itself chains FFmpeg for file reading; an audio pre-amp for an initial volume change; SoX for resampling and dithering; and a ReplayGain processor for final volume change.

Features:
  • As is common for input plug-ins, you can choose exactly what file types it applies to (via a list of file name extensions).
  • It potentially reads anything FFmpeg can, including video files. Support for some formats may require replacing FFmpeg DLLs after installation, however.
  • When reading video files, the video can be shown or ignored. If ignored, the enabled visualization (if any) can be shown instead.
  • Audio and video buffering are both configurable.
  • Audio output bit depth can be 16 or 24.
  • All internal audio processing is done in 32-bit floating-point.
  • The pre-amp can modify the volume by ±12.0 dB.
  • SoX processing (resampling and dither) can be enabled always, never, or only when needed.
  • Resampling quality can be reduced for speed (quality choices are Quick, Low, Medium, High, Very High).
  • The desired output sample rate can be an absolute requirement (forcing up- or down-sampling of any other input rate) or it can be a minimum acceptable rate (forcing up-sampling only).
  • The actual output sample rate can be forced to be an integer multiple of the input rate; desired rate will be considered a minimum acceptable multiple.
  • Many types of dither are available.
  • The ReplayGain processor has a slider allowing album and track gain to be mixed in any ratio.
  • Pre-amp & ReplayGain diagnostic info can optionally replace comment tag data in the File Info dialog (Alt+3).
  • A separate group of all of the audio settings is available for use by Winamp's Format Converter.


The TOS#8-violating theory behind its development notwithstanding, it turns out that the plug-in does solve a very real and obvious sound-quality problem for me.

The SHOUTcast DSP for Winamp does some wickedly poor-quality resampling if its input isn't at the sample rate required by whatever codec is chosen for the DSP's output. For me, that generally means that 48 KHz files get resampled to 44.1 in a way that result in some atrocious artifacts that I think anyone can hear:

The FFSoX Player input plug-in resolves this issue. I have it simply resampling always to 44100, and handling all the types of files in my playlist. Since the DSP receives already-resampled audio from the input plug-in, no further resampling is applied, and my stream sounds just fine. Many thanks to Peter for helping me get it working.

Suggestions for improvement: The meaning of "Minimum" and "Multiple" isn't obvious; there should be a tooltip or more descriptive labels explaining what they do. The ReplayGain processor needs to implement clipping prevention. There should be documentation about what file types aren't supported by the FFmpeg DLLs shipped with the plug-in, so you know in advance whether you need to replace them.

This post has been edited by mjb2006: Dec 8 2013, 07:03
Go to the top of the page
+Quote Post

4 Pages V  « < 2 3 4
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th April 2014 - 14:55