ffdshow / libsamplerate

[Jorgosch]

Is there a chance to get ffdshow audio compiled with the new libsamplerate (http://www.mega-nerd.com/SRC/download.html) 0.1.3? It's a much improved version that came out a few weeks ago.

[clsid]

Binary for new version is ten times as large as the old one. Seems to due some overly aggressive optimizations. Makes the ffdshow installer grow with 800 KB. I don't think I am going to commit it.

[Jorgosch]

1.4 is out but I'm guessing the size concerns are the same.

[clsid]

Judging from the version history, I assume that the size issue hasn't changed with 0.1.4.

[yesgrey]

I have updated ffdshow's libsamplerate to version 0.1.4.

Here is the ff_samplerate.dll built with ICL10.1:
http://www.megaupload.com/?d=NBHP81YX

Here are the source files that were updated:
http://www.megaupload.com/?d=HWU6Q3LD

If you want to test the new version, overwrite the "ff_samplerate.dll" file (located in your ffdshow's install directory) with the one linked above. Post here your opinion. If the new libsamplerate is really better than libavcodec, I suggest the ffdshow developers to update it to the new version (I include the files above). If it's quality is not worth it, the better is keeping ffdshow as it is. It does not make any sense to increase the size of ffdshow's installer with something that does not give any increase in quality.

[pitch.fr]

obrigado yesgrey, gonna try it....right now :D

[yesgrey]

obrigado
You're welcome (De nada)

Your portuguese skills are improving...:)

[rickardk]

Great!!
Thanks yesgrey3!

[henryho_hk]

It will be nice to maintain it as an official optional package.

[yesgrey]

Should be released in a few days a new libsamplerate version: 0.1.5.
It received several code changes for increasing the speed, keeping the same quality as previous version 0.1.4. It only affects the 3 sinc modes - the modes used in ffdshow.

I had access to a pre-release version, 0.1.5pre2, and have updated ffdshow's libsamplerate to this version.

Here is the ff_samplerate.dll built with ICL10.1:
http://www.megaupload.com/?d=YDR9ARGV

Here are the source files that were updated:
http://www.megaupload.com/?d=V8MND75Y


If you want to test the new version, overwrite the "ff_samplerate.dll" file (located in your ffdshow's install directory) with the one linked above. Post here your opinion.

If you want to see the speed increase compared with the previous version, 0.1.4, go here (http://forum.slysoft.com/showthread.php?t=24236). I have also updated Reclock's resampler, which is based in libsamplerate, so the performance gains you will get in ffdshow should be compared.

Note for the developers: This code should be compiled with a 1999 ISO Standard C compiler. I have used ICL10.1, but /Qstd=c99 should be added to the compiler options.

[leeperry]

Here is the ff_samplerate.dll built with ICL10.1:
http://www.megaupload.com/?d=YDR9ARGV
looks good, thanks!

I've just switched headphones, and I got a question for you :D

I used to have some high end Sony MDR-CD3000 cans, on my bit-perfect M-Audio Audiophile USB...that I've now switched for some modded Beyer DT770 Pro/250.

they have less refined trebles, less transparent but also much less fatiguing...but much better bass( this test is fully audible up to 20Hz, it stopped at 60Hz on the SONY : http://www.tfm.ro/ac3/download/test_ac3.rar ) and the isolation is much better, I've also changed the cable for a Monster OFC & I'm adding damping in the cups.

anyhow these are highly accurate phones, small glitches and crackles literally explode to your face! :eek:
these are truly unforgiving, where the SONY wasn't so analytical.

anyway, long story made short resampling sounds a lot brighter(better?)

is it because -as this guy believes- it smoothes the waveforms ?
http://photos.imageevent.com/cics/v03theartofbuildingcomputertrnsp/The%20art%20of%20building%20Computer%20Transports%20v0.3.pdf

http://www.image-load.eu/out.php/i142679_src.png

I know it adds distorsion and stuff(bringing us closer to the analog source as he says?), but this guy seems to really know what he's talking about(his tutorial is highly educational), and my 2 cans seem to bring me to the same conclusions.

and that would also explain why a 24/96 downsampled to 16/44.1 then resampled to 24/96 is said to be very hard(if not impossible) to differenciate from the source in ABX tests?

libsamplerate seems less bright than libavcodec, is it the additional distortion that actually makes the sound brighter :confused:

or is it because my sound card internally resamples to 96KHz anyhow ?!

BTW I've done an audio checkup last week, my audition is very good from what the doctor said.

:thanks:

[madshi]

As far as I know, brighter sound after resampling (compared to the original source) usually means more artifacts/aliasing. Using upsampling I think the sound shouldn't get brighter. If you notice any difference at all, if probably should get a little bit smoother or "less digital", but not brighter. But I'm not really an expert here...

Have you tried how eac3to's SRC compares to libavcodec and libsamplerate? :)

[tetsuo55]

There are a lot of resamplers and a lot of settings/options.

converting to 24/92 when your soundcard uses that internally means the soundcard will not re-convert it a second time.

for best results feed your soundcard what it uses internally.
(In my case X-Fi, the core uses 32/96 and the DAC does 24/96 so i convert any to 32/96)

[leeperry]

converting to 24/92 when your soundcard uses that internally means the soundcard will not re-convert it a second time.

for best results feed your soundcard what it uses internally.
(In my case X-Fi, the core uses 32/96 and the DAC does 24/96 so i convert any to 32/96)
you can bypass the SRC in "audio creation mode"+"bitmatch playback" on the X-Fi....but its SNR/THD are so bad that it doesn't really matter.

well yeah I've always suspected that the drivers were resampling everything to 24/96 anyhow...as this sound card is not quite a "sound card" but more of a DAC.

its PCB only has only one PLL clock and no DSP at all :

http://www.image-load.eu/out.php/t142933_ma3456udioaudiophileusbqr3.jpg (http://www.image-load.eu/out.php/i142933_ma3456udioaudiophileusbqr3.jpg)

or even if it doesn't resample, maybe the DAC is doing some low quality upsample to its native res?

It would appear that what increases the brightness is indeed the distortion, but I find the sound much more "alive" & airy...in bit-perfect output of course(no KMixer) :rolleyes:

I will try to use noise shaping in ffdshow to output 24/96, atm I'm outputting 32 float/96(which sounds "better" and reinforces the theory that the pesky drivers are resampling anyhow :o )

and I don't really get the subtility between resampling and upsampling....I will read the man's PDF once more :D

[leeperry]

http://musicindustrynewswire.com/2007/03/02/min158_212834.php

Some dithering algorithms may also add artificial brightness or presence that occasionally may be perceived as beneficial, however in most cases you are better off leaving the material at the original sampling rate and bit resolution.

haha, "in most cases"...that helps A LOT :D

actually I'm also using Ozone3 in ffdshow in 32 float, and it works in 64 float internally :
http://www.izotope.com/tech/src/

[tetsuo55]

A dac does no resampling.

All it does is take 1's and 0's and turns those into voltages.
The DAC's limits(24/96) only limit the maximum amount of precision. Feeding it with a higher signal will result in clipping of the extra data.

I use :

Foobar2000 (pad to 32bit, dithering enabled)(dithering does nothing when going to a higher bitrate)
Sox resampler (resample to 96 in high quality)
Noisesharpener (100%, very good alternative to ozone3, my family prefers it over everything else (even above no filtering))
autolimiter (only does something when needed)
change channel setup from 2.0 to 2.1 (i have small speakers)
Kernel streaming (asio doesn't support 5.1)

[leeperry]

well, what does my DAC *really* do when I feed it 16/44.1 or 48? considering its native res is 24/96...it's a good guess it will upsample to its native res using cheapo techniques.

and when I output 32 float from ffdshow, it's got no other choice than to convert to 24 integer I guess ?

you were complaining about your X-Fi DSP resampling everything on the fly, that's why I said you could run in "audio creation mode" + "bitmatch playback" to bypass all that stuff.

but the THD/SNR measurements from this jap site are so bad, that it doesn't really matter IMHO :
http://www.dosv.jp/feature/0602/16.htm
http://www.dosv.jp/feature/0602/17.htm
http://www.dosv.jp/other/0612/21.htm
http://www.dosv.jp/other/0612/22.htm
http://www.dosv.jp/other/0612/23.htm
http://www.dosv.jp/feature/0702/17.htm
http://www.dosv.jp/feature/0802/24.htm
http://www.dosv.jp/feature/0802/25.htm

creative cards are poorly engineered, w/ bad shielding/design and low quality opamps :o

I'm not too fund of foobar, it can't even use winamp2 plugins/wrappers in 32 bits float....I very much prefer ffdshow, that even supports noise shaping :)

but I'll try your noisesharpener plugin, it sounds intriguing....too bad it doesn't work in ffdshow :o

[tetsuo55]

well, what does my DAC *really* do when I feed it 16/44.1 or 48? considering its native res is 24/96...it's a good guess it will upsample to its native res using cheapo techniques.

and when I output 32 float from ffdshow, it's got no other choice than to convert to 24 integer I guess ?

The DAC does not care what you send it. the whole system is based around least-significant-bytes. Uncompressed digital audio will always be in the correct order for a DAC.

-More bits than it can handle are simply clipped, less bits simply means those registers stay at 0
-Higher frequency is ignored, the dac simply works at the highest frequency it can, when feeding it a lower frequency it simply uses that exact frequency



you were complaining about your X-Fi DSP resampling everything on the fly, that's why I said you could run in "audio creation mode" + "bitmatch playback" to bypass all that stuff.

but the THD/SNR measurements from this jap site are so bad, that it doesn't really matter IMHO :
http://www.dosv.jp/feature/0602/16.htm
http://www.dosv.jp/feature/0602/17.htm
http://www.dosv.jp/other/0612/21.htm
http://www.dosv.jp/other/0612/22.htm
http://www.dosv.jp/other/0612/23.htm
http://www.dosv.jp/feature/0702/17.htm
http://www.dosv.jp/feature/0802/24.htm
http://www.dosv.jp/feature/0802/25.htm

creative cards are poorly engineered, w/ bad shielding/design and low quality opamps :o

My current foobar2000 setup gets the same result without sacrificing other usefull effects that get disabled with audio creation mode, my model has medium quality DAC's.
(eventually i want LPCM>HDMI>Reciever>DAC) The reciever i am planning on buying has very good 24/192 DAC's


I'm not too fund of foobar, it can't even use winamp2 plugins/wrappers in 32 bits float....I very much prefer ffdshow, that even support noise shaping :)

but I'll try your noisesharpener plugin, it sounds intriguing....too bad it doesn't work in ffdshow :o

The only plugins i miss are the game-music-emulation ones, but i could get those through the winamp wrapper. Other than that all i need is in foobar2000 with the plugins i mentioned.

That noisesharpening plugin is really good, it has even convinced some bit-perfect folk. It is a lot better than anything ffdshow offers.



My wish is that eventually i could get the exact same setup as i have in foobar2000 in ffdshow for movies.

[leeperry]

I think bit-perfect output is important so KMixer doesn't ruin our efforts :)

but I don't believe in bit-perfect processing, as Ozone3 yields fantastic results :eek:

you can slightly increase the soundstage at different % depending on the frequencies bands, slightly compress the bass to get more kick, add very slight reverb to the voices frequencies to get a more "live" sound in movies, add tape saturation to the mids so they sound less "digital" and use the valve EQ to match your sound system native bandwidth...a bit like an ICC calibration profile.

anyway, I'll run more tests....as I understand it, what truly matters is the end user satisfaction :p

[iSunrise]

Finally I got my new Core i7 system well setup, I want to proceed with testing different ffdshow builds (x86 icl10, mt and x64) and especially resampling thoroughly. I have one question though:

Is the resampler build that yesgrey3 provided for use in ffdshow exactly the same as the O3 build on the slysoft forum?

@leeperry:
How can I do accurate comparisons between the different resampler builds with ffdshow? I know there´s TimeCodec for video, is there something for audio, too? Thanks.

[leeperry]

well switch them on the fly, your ears will judge whichever one you prefer :)

I think I still prefer libavcodec on my new cans, as it was already the case on the cd3k.

EDIT: oh well, when resampling to 96KHz then using Ozone3, libavcodec sometimes makes a big glitch at the beginning of the file....doesn't happen w/ your libsamplerate DLL :)

[yesgrey]

Is the resampler build that yesgrey3 provided for use in ffdshow exactly the same as the O3 build on the slysoft forum?
It's the same libsamplerate version, 0.1.5, with the same ICL10.1 optimizations (O3), but it's not the same build, because there are some minor differences between ffdshow and reclock usage code. This means you cannot use reclock's dll in ffdshow or vice-versa.;)

[leeperry]

ok I guess my question was tricky to begin with :D

anyhow, enabling resampling in ffdshow is slow...it takes noticeably longer to open an audio file, and makes a big glitch at the start if using libavcodec...so I don't resample anymore and use 2 DX/VST plugins in ffdshow, does the job very nicely :

http://www.image-load.eu/out.php/i143208_vst0.png

http://www.image-load.eu/out.php/i143213_dx.png

[leeperry]

My wish is that eventually i could get the exact same setup as i have in foobar2000 in ffdshow for movies.
well the VST winamp2 wrapper doesn't work too well in ffdshow(due to ffdshow killing the DLL before closing it), but FFX-4 works like a charm...plus its coder is a friend of mine so it's easier :D

anyway, this sounds just like what I wanted, on FLAC(thanks madshi for the DS decoder!), MP3 and movies(MPC for music coz it opens faster, KMP for movies coz it's got far more features)

http://www.image-load.eu/out.php/t143798_eek.png (http://www.image-load.eu/out.php/i143798_eek.png)

you can't beat the SSL sound :p

The unique sound of Solid State Logic’s 4000 Series analogue mixing consoles is sought after worldwide. Engineers of pop and rock music, broadcast transmissions and television post-production value the SSL 4000’s flexible dynamics chain as much as the trademark SSL “punchy” sound. Waves and SSL engineers have worked together for over a year to
recreate the sound characteristics of the classic SSL 4000 Series E and G Series consoles. Now, those who “mix in the box” can achieve the sound they thought they’d lost when they moved to the digital world.

[yesgrey]

libsamplerate was updated to version 0.1.7.
Some small bugs correction, and was changed to not require an ANSI C 1999 compiler anymore.

Here is a pack with x86 and x64 builds I have created using VS2008:
http://www.megaupload.com/?d=UHP9863Y

The source files, in case ffdshow developers want to update libsamplerate included in ffdshow (still 0.1.2):
http://www.megaupload.com/?d=CBRO2L2L

[leeperry]

I will look into it, thanks! http://forum-images.hardware.fr/images/perso/d4buff.gif

[leeperry]

http://www.thetadigital.com/upsampling.htm

In systems with high quality digital components, "upsampling", especially in the sense of outboard, additional devices should be regarded with a great degree of caution.

[tetsuo55]

Nice link,

So the upsampling actually does help.
Being able to control the upsampling ourselves is a big bonus, as we can select the best algorithm.

Manual upsampling can reduce the perfomance of some high quality dac's.

I think this is not an issue with the quality of upsamplers we are using here.
We would need independent testing.

I doubt anyone here has a system that falls into degrading category though.

Finally, the jitter he talks about is so terrible in a PC system that it really doesn't matter anymore.
Programmers need to focus on outputting jitterfree audio(and video) from PC's and recievers need to correct jitter on their inputs.

[yesgrey]

Finally, the jitter he talks about is so terrible in a PC system that it really doesn't matter anymore.
Programmers need to focus on outputting jitterfree audio(and video) from PC's and recievers need to correct jitter on their inputs.
Not necessarilly. See this link (http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_steadyclock).
Some high quality computer soundcards have very low jitter.

[leeperry]

all I know is that resampling in ffdshow makes the sound brighter and more distorted....but this is upsampling, not oversampling....these are 2 different animals, or not :D

[tetsuo55]

Not necessarilly. See this link (http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_steadyclock).
Some high quality computer soundcards have very low jitter.

Nice products, but only a very small portion of the world's population have one of these, and also only a few of their models actually have such a low jitter, and most of those cannot even be connected to speakers directly...

all I know is that resampling in ffdshow makes the sound brighter and more distorted....but this is upsampling, not oversampling....these are 2 different animals, or not :D

I believe what we are doing with ffdshow is Re-Sampling at a higher sample rate than the original source, as libsamplerate is very aware of the problems with frequencies it applies the same principals as up/over-sampling as described in your link.
It basically does all 3 in one go if i understood it correctly.

[henryho_hk]

Would you mind making a win64 compile?

[yesgrey]

Would you mind making a win64 compile?
I have updated my link here (http://forum.doom9.org/showpost.php?p=1252766&postcount=25) with it.
Let me know if it's working. It's my first x64 build and I don't have a x64 OS installed to test it... soon I will install Server2008 64bit just for having a feeling about it...

[leeperry]

I've found a very interesting link about DAC/oversampling and stuff :
http://www.iar-80.com/page25.html

it's being discussed here : http://www.head-fi.org/forums/f133/24bit-vs-16bit-myth-exploded-415361/index16.html

more here : http://www.iar-80.com/page21.html

A conventional CD has only 16 bits, and a Sony DSD master tape has only 8 effective bits of resolution. But IAR research showed long ago that the human ear/brain can hear finer than 20 bits of resolution on music. Since the human ear/brain can discern, apprise, and appreciate the true musical waveform to an accuracy of 20 bit resolution, it follows that any representation of that same music waveform with cruder resolution, e.g. only 16 bit quantization, will only crudely approximate the true and audibly discernible amplitude value of the music waveform for each sample point, and will be somewhat erroneous at each sample point. Is there a way to do this? Yes. Increase the sampling rate! If the averaging algorithm has twice as many sample points to average for improving a given audio frequency, then it can do at least twice as good a job, at that frequency, of reducing various digital errors and improving the accuracy of the music waveform. High power averaging algorithms can do even better than twice as well, depending on the curves engineered into the algorithm. If we double the sampling rate, we double the number of sample points per cycle at every audio frequency.

The information for improving the true resolution of one sample point comes from many other nearby sample points. It comes from the average trend of these many other sample points. The accurate, original music waveform is already contained within, but hidden among, the statistical scatter of digitized samples which, thanks to the crude approximation of 16 bit quantization, vary from the correct waveform value in a random, noiselike way. High power averaging finds and calculates this original music waveform hidden amongst the statistical noisy scatter, by using the information contained in many sample points, to reduce the noisy quantization errors, and thereby improve the accuracy and resolution of each of the sample points. Thus, musical resolution can truly be improved (at least for middle and lower frequencies), even beyond the coarse limitations of the original 16 bit digitizing.
That's why some CD players like the Capitole, some D-A processors, and some outboard boxes like the dcs Purcell can make your 16 bit CDs sound better (as though they had the same 20-24 bit resolution as the new super digital formats) -- revealing more musical detail with higher resolution, and also sounding more musically natural, since the averaged waveform they create is truer to the original music waveform than the crudely approximate 16 bit input digitization was.

[leeperry]

http://www.iar-80.com/page21.html

It required the much more aggressive 9th order noise shaping to energize the Purcell's capabilities, and furnish a significant sonic improvement over 16/44 CD.

there's no such thing on PC, right?

[tetsuo55]

I have not read the links you posted.

But that has to be the first confirmation of something i calculated a long time ago.

It has been scientficially proven that humans respond to more than just the hearable frequency.

Frequency
*The highest frequency possible at sea level is 3GHZ
**The nyquist limit thus says we need to sample at 6GHZ to be able to restore the entire range.

Bitrate (decibel's)(i forgot most of this so there could be a little mistake)
*The dynamic range at sea level is about 240 (-46 to +194)
**The maximum difference in pressure a human can detect is 0,2 DB
**to restore this hearable difference(and more) only 64bit floating point is needed

**Changes in athomspheric conditions can change these numbers, vulcanic eruptions change the air in such a way that higher frequencies and decibels are possible, but because you can not(and would never want to) recreate this with speakers in the home you can ignore those.

The only real problem with this is that starting from 85DB the sound pressure starts to become dangerous, 120DB and up is deafning and 160 and up is deadly.
Also some frequencies between 40k and 3ghz cause tissue and bone damage too.

So a lot more research would be needed to create near-lossless but safe sounds (loads and loads of dynamic compression for a National geographic show featuring a active vulcano)

[leeperry]

I've read several pages on that site, it mostly sounds like commercial bs for a $12K DAC :D

I've got some 24/96 DVD-A that sounds really good, some SACD that sound out of this world....and some 24/96 remastered CDDA that almost sound just as good :confused:

and my best sounding DVD-A is 24/44.1 :D

probably what truly matters is that they used some fantastic dithering(like they say this DAC does) + top-notch microphones(Neumann U87?), top notch everything ya know...TLA preamps, etc etc....

the higher the resolution/sampling freq, the easier it is to get good results....but w/ the right gear and source material you can make a CDDA sound great.

but when I compare the SACD of Depeche Mode "Violator" downmixed to stereo w/ the Logic7 binaural matrix VS the CDDA version...there's like a HUGE gap between these :eek:

even their latest album sounds flat and poorly mixed in CDDA, I think DSD is simply far more "musical" than LPCM :o

as they say on this site, DSD is only 8bit but uses tons of dithering/psychoacoustic principles.

[leeperry]

ok, about noiseshaping/oversampling...to get back to the idea that all DAC's are not equal when it comes to reconstructing the original waveform from a 16/44.1 audio file....what do you guys think of that "VLSC" Onkyo thingie :
Translated version of http://www.e-onkyo.com/goods/detail.asp?cgds_id=SEU33GXVB&ictg_no=34 (http://209.85.229.132/translate_c?hl=en&sl=ja&u=http://www.e-onkyo.com/goods/detail.asp%3Fcgds_id%3DSEU33GXVB%26ictg_no%3D34&prev=/search%3Fq%3DSE-U33GXP%26hl%3Den%26safe%3Doff%26sa%3DG%26num%3D20&usg=ALkJrhilIJvKYVfs3FyRklMq_ykM7xikBA)

TECHNOLOGY | ONKYO Asia and Oceania Website (http://www.intl.onkyo.com/technology/glossary/vlsc.html)

http://www.intl.onkyo.com/technology/glossary/vlsc.html

http://www.intl.onkyo.com/technology/img/tec_image/i_vlsc_la.gif http://www.e-onkyo.com/goods/detailimg/SEU33GXVB_s2.jpg

I might take the plunge on one of these :D

[markanini]

Is libsamplerate in the latest ffdshow tryout builds still v0.12? Official changelog didnt mention anything.....
EDIT: Dug out an old thread about developer relutance to include newer versions due to massive increase in distribution size.
How about SoX? Feasible to include with ffdshow, or make a special build? If anything it has an edge over most resamplers together with Izotope SRC according to that site with the pretty graphs. You know the one guys.

[XhmikosR]

Actually the current version is v0.1.2. Don't know about the size you mention, but there are some changes mentioned in libsamplerate's changelog (http://www.mega-nerd.com/SRC/ChangeLog). I don't know if it's worth updating to the latest 0.1.7.

[markanini]

The author of lbsamplerate mentions quality and speed improvements on his blog. On the other hand libavcodec is actively developed and yesgrey3 seems to like how it sounds. Do you know any easy way to run WAVs through ffdshow and save the output in an offline fashion? I mean like not realtime but as fast as the cpu can manage. I'd like to analyse the output with a spectrogram. SoX rate would still be cool, it's undisputed among free resampling software IMHO, but maybe libavcodec makes more sence for realtime performance.

[Thunderbolt8]

whats the general opinion now, does libavcodec or libsamplerate provide better re(down)sampling quality?

[Midzuki]

Speaking of the MegaNerd :) it would be nice if john33 @ rarewares.org wrote and compiled an up-to-date build of SRCdrop.exe :cool:

[john33]

Speaking of the MegaNerd :) it would be nice if john33 @ rarewares.org wrote and compiled an up-to-date build of SRCdrop.exe :cool:
I'll get to it very soon. :)

I have a hard time keeping up with new releases. ;)

[john33]

New compile of SRCDrop is now at Rarewares. :)

[Midzuki]

@ Thunderbolt8: The Secret Rabbit :D is slower than libavcodec, "because" :rolleyes: it IS better :cool:

( not that my old ears can notice the difference, though :o )

New compile of SRCDrop is now at Rarewares. :)

:goodpost: AND

:thanks: :thanks: :thanks: :thanks: :thanks:

[tebasuna51]

Thanks john33 by your quick work

[Thunderbolt8]

can i use SRCDrop with ffdshow audio?

edit: i see its just a conversion tool. is that version of libsamplerate integrated in ffdshow up todate?

[markanini]

can i use SRCDrop with ffdshow audio?

edit: i see its just a conversion tool. is that version of libsamplerate integrated in ffdshow up todate?

Yes, v0.18.