Reclock's Resampler version 0.1.7 ICL11

[yesgrey3]

Reclock's resampler is an independent part of Reclock. So, I think it's better keeping any discussions about it in a separate thread.

Ogo used the Secret Rabbit Code resampler, also know as libsamplerate.
The official page is here (http://www.mega-nerd.com/SRC/index.html).

The original resampler, part of ogo's reclock's versions, was based on libsamplerate version 0.1.2.
A few months back, I realized that a new version of libsamplerate was available (0.1.4) that improved greatly the quality of the three best resampling modes, and suggested to James to update the resampler's code. He accepted my offer, and the current resampler distributed with reclock is based on libsamplerate version 0.1.4.

A few days back, I was informed that a new version of libsamplerate will be available soon (0.1.5). This new version has several code optimizations to increase the speed. We should expect double the speed (or half the cpu load) when comparing with the previous version, but the quality is exactly the same. Once again, this only affects the three best modes (Excellent, Very Good and Good).

As soon as the code is officially released, I will post here the source to let James include his own build in reclock's installer.
Until then, I will post here my builds only for testing purpose...

Here is a file with several builds, with different compiler options. I use only ICL10.1 (Intel C++ compiler). I would like if you could test all the builds (including the previous 0.1.4) and post your results here. Please use only Reclock's cpu load meter.
For now, I only have created generic (for all cpus) builds, and Intel Core2 Duo (only for Intel Core2 Duo cpus and up) builds.
The MT suffix indicates a build with some multi-threading performed automatically by the compiler.
The SSSE3 suffix indicates a build only for Intel Core2 Duo processors and up.

EDIT: Updated resampler to version 0.1.7. Some bugs correction.
You can download here the Intel C compiler 11.0 build:6208
Download it. Unzip it. Substitute the Resampler.dll file in Reclock's install directory.

[yesgrey3]

Here are my test results...

Windows XP, Intel E2160@3.15GHz(9*350) - 1MB cache

dvd movie: 6 channels ac3 448kbps 48kHz 32 bit pcm - Quality: Excellent

0.14 ICL10.1_O2 : 51%
Resampler_ICL10.1_O2 : 40.5%
Resampler_ICL10.1_O2_MT : 40.8%
Resampler_ICL10.1_O2_SSSE3 : 44.0%
Resampler_ICL10.1_O2_SSSE3_MT : 46.0%
Resampler_ICL10.1_O3 : 39.7%
Resampler_ICL10.1_O3_MT : 39.3%
Resampler_ICL10.1_O3_SSSE3 : 44.2%
Resampler_ICL10.1_O3_SSSE3_MT : 45.3%

dvd movie: 6 channels ac3 448kbps 48kHz 32 bit pcm - Quality: Very Good

0.14 ICL10.1_O2 : 9.1%
Resampler_ICL10.1_O3 : 4.2%
Resampler_ICL10.1_O3_MT : 4.3%

dvd movie: 6 channels ac3 448kbps 48kHz 32 bit pcm - Quality: Good
0.14 ICL10.1_O2 : 4.3%
Resampler_ICL10.1_O3 : 2.2%
Resampler_ICL10.1_O3_MT : 2.4%

dvd movie: 6 channels ac3 448kbps 48kHz 32 bit pcm - Quality: Medium
Resampler_ICL10.1_O3 : 0.9%

dvd movie: 6 channels ac3 448kbps 48kHz 32 bit pcm - Quality: Low
Resampler_ICL10.1_O3 : 0.8%


The quality "Excellent" is too cache intensive. So, my results with the new release are not half the cpu load...
With the other quality modes, I get half the cpu load.

Comparing the cpu loads of Good vs Medium vs Low, maybe it's time to consider removing the Medium and Low quality modes and keep only the qualities Excellent, Very Good and Good...

[leeperry]

so here we go, on XP SP3 & a Q6600@3.3GHz(8*415) w/ heavy ffdshow/avisynth post-processing...Quality: Excellent :

stereo ac3 32/96

0.14 ICL10.1 : 21
Resampler_ICL10.1_O2 : 13.5
Resampler_ICL10.1_O2_MT : 12.5
Resampler_ICL10.1_O2_SSE3 : 18
Resampler_ICL10.1_O2_SSE3_MT : 19.5
Resampler_ICL10.1_O3 : 11
Resampler_ICL10.1_O3_MT : 11.5
Resampler_ICL10.1_O3_SSE3 : 18
Resampler_ICL10.1_O3_SSE3_MT : 19

6 channels 1.5mbit dts 32/96

0.14 ICL10.1 : 61
Resampler_ICL10.1_O2 : 21
Resampler_ICL10.1_O2_MT : 21.5
Resampler_ICL10.1_O2_SSE3 : 30
Resampler_ICL10.1_O2_SSE3_MT : 29
Resampler_ICL10.1_O3 : 21
Resampler_ICL10.1_O3_MT : 21
Resampler_ICL10.1_O3_SSE3 : 33
Resampler_ICL10.1_O3_SSE3_MT : 35

compares between the 2 fastest builds on several movies :

6 channels 1.5mbit dts 32/96

Resampler_ICL10.1_O3 : lowest 20.4 / sits at 21
Resampler_ICL10.1_O3_MT : lowest 20.3 / sits at 23

6 channels 1.5mbit dts 32/96

Resampler_ICL10.1_O3 : lowest 20.6 / sits at 23.5
Resampler_ICL10.1_O3_MT : lowest 20.6 / sits at 24

2 channels 1.5mbit dts 32/96

Resampler_ICL10.1_O3 : lowest 10.8 / sits at 15
Resampler_ICL10.1_O3_MT : lowest 10.7 / sits at 14

2 channels 1.5mbit dts 32/96

Resampler_ICL10.1_O3 : lowest 10.9 / sits at 15
Resampler_ICL10.1_O3_MT : lowest 10.4 / sits at 16

2 channels 1.5mbit dts 32/96

Resampler_ICL10.1_O3 : lowest 11.3 / sits at 17 http://thumbnails4.imagebam.com/2150/bbb2d421497038.gif (http://www.imagebam.com/image/bbb2d421497038)

Resampler_ICL10.1_O3_MT : lowest 10.8 / sits at 16 http://thumbnails5.imagebam.com/2150/e2802121497037.gif (http://www.imagebam.com/image/e2802121497037)

2 channels 1.5mbit dts 32/96

Resampler_ICL10.1_O3 : lowest 10.3 / sits at 13.8 http://thumbnails4.imagebam.com/2150/0ae0a221497048.gif (http://www.imagebam.com/image/0ae0a221497048)

Resampler_ICL10.1_O3_MT : lowest 11.7 / sits at 13.8 http://thumbnails2.imagebam.com/2150/4f26b421497047.gif (http://www.imagebam.com/image/4f26b421497047)

[leeperry]

top is ICL10.1_O3 / bottom is ICL10.1_O3_MT

http://thumbnails9.imagebam.com/2150/3c519321497041.gif (http://www.imagebam.com/image/3c519321497041) http://thumbnails8.imagebam.com/2150/ec71a921497043.gif (http://www.imagebam.com/image/ec71a921497043)

http://thumbnails4.imagebam.com/2150/95a43421497039.gif (http://www.imagebam.com/image/95a43421497039) http://thumbnails4.imagebam.com/2150/ae8f9621497042.gif (http://www.imagebam.com/image/ae8f9621497042)

[leeperry]

top is ICL10.1_O3 / bottom is ICL10.1_O3_MT

http://thumbnails5.imagebam.com/2150/c0358321497045.gif (http://www.imagebam.com/image/c0358321497045)
http://thumbnails4.imagebam.com/2150/b9b6ed21497044.gif (http://www.imagebam.com/image/b9b6ed21497044)

[ashlar]

??? SSE3 builds perform less?

[yesgrey3]

The SSSE3 builds allow the creation of code using all SIMDs up to SSSE3. It doesn't mean that SSSE3 are used, but that could be used...

I think this is an algorythm that doesn't benefit from the SIMDs.

From my tests, and leeperry tests, I think it's better keeping just the generic O3 build. It will run in all cpus and will perform the best.

[leeperry]

I think it's better keeping just the generic O3 build.
agreed :rock:

[kaker]

Hi. All these are the software resampler, right? So it's normal that using "Do hardware resampling" I don't notice anything?

[Guster]

I have just done a shortened test as my results mirror those above :
XP3 E5200 @2.5Ghz

Xvid mp3 2 channel audio.

0.14 ICL10.1 : 14.9
Resampler_ICL10.1_O2 : 9.8
Resampler_ICL10.1_O2_MT : 9.9

Resampler_ICL10.1_O3 : 9.7
Resampler_ICL10.1_O3_MT : 9.8
Resampler_ICL10.1_O3_SSE3 : 12.8

[yesgrey3]

Hi. All these are the software resampler, right? So it's normal that using "Do hardware resampling" I don't notice anything?

Yes. Hardware resampling bypasses the software resampler.

[_mulder]

Yes. Hardware resampling bypasses the software resampler.

Just a quick question. I am currently using hardware resampling (I have a Sondigo analog soundcard). Would I get better sound using sofware resampling or there won't be much difference.

Thanks

edit: I did not meant to hijack the thread. I can start a new thread if more appropriate

[James]

Just a quick question. I am currently using hardware resampling (I have a Sondigo analog soundcard). Would I get better sound using sofware resampling or there won't be much difference.

Thanks

edit: I did not meant to hijack the thread. I can start a new thread if more appropriate

Well, try it out. Use whatever pleases your ears.

[yesgrey3]

I did not meant to hijack the thread. I can start a new thread if more appropriate

You haven't hijacked the thread. My original idea was creating this thread to discuss reclock's resampler, and all stuff related to it. I think hardware resampling also fits here. Unfortubatelly, all the discussion keeps going in the main sticky thread...

[red5goahead]

imho the very good level is the best choice.
the difference between two resample in cpu load terms is important. :)
with an mvk 1280x720 with 6 ch. in dxva mode. the cpu load was 15% with old resample. 9% with new resample . 3% with hw resampling
(looking the cpu graph and cpu medium load value in the Vista monitoring)

a question: the audio video desynch using audio timestreching and ac3 encoder is related to resample, the audio timestreching , the encoding or the sum of these processes?

[yesgrey3]

imho the very good level is the best choice.

Yes, I think it would be a good idea if James removes the Medium and Low quality modes, and set the Very Good as the Recommended. It would simplify Reclock configuration, and would be more indicated for the current resampling speeds and cpus.

@James
With Christmas, maybe the release of the new version will be a little delayed by the author. Do you want me to upload now the current source code, so you could compile your own build? I believe it will not change and apparently is working good with everyone who have tested it...

[red5goahead]

Yes, I think it would be a good idea if James removes the Medium and Low quality modes, and set the Very Good as the Recommended. It would simplify Reclock configuration, and would be more indicated for the current resampling speeds and cpus.

@James
With Christmas, maybe the release of the new version will be a little delayed by the author. Do you want me to upload now the current source code, so you could compile your own build? I believe it will not change and apparently is working good with everyone who have tested it...

and the cpu load indicate in reclock is not related to its player task.
so the resample spent really low cpu resources

http://img140.imageshack.us/img140/7473/67987114pq7.th.jpg (http://img140.imageshack.us/my.php?image=67987114pq7.jpg)

[James]

@James
With Christmas, maybe the release of the new version will be a little delayed by the author. Do you want me to upload now the current source code, so you could compile your own build? I believe it will not change and apparently is working good with everyone who have tested it...

I can hold out a little... I am busy with BD+ & Co. at the moment anyway. ;)

[Jong]

Hi Yesgrey3,

Can you link to the final, agreed, optimised, compiled version of the Resampler? I'm using the one you posted in the Reclock support thread shortly before this thread was opened. Not sure if the source or the compiler choices have changed since.

[James]

@James
With Christmas, maybe the release of the new version will be a little delayed by the author. Do you want me to upload now the current source code, so you could compile your own build? I believe it will not change and apparently is working good with everyone who have tested it...

With BD+ and Sony Arccos off my back for a little moment, now would be the perfect time for a new ReClock release. Could you post the current sources? Thanks a lot!

[LINUS]

now would be the perfect time for a new ReClock release

Yes, expiration date is getting closer.

Thanks in advance (though I do not have any problems with the current version!)

[yesgrey3]

Can you link to the final, agreed, optimised, compiled version of the Resampler?
The link is on the first post of this thread. But remember is not yet the final. After James release his build, let's compare it with the one linked here and if Jame's build is faster I will remove my link. Please post here the compare results.

Could you post the current sources?
James, here it is:
5500
Remember this is not the official release, is still 0.1.5pre2. I will contact the author to ask him if we could consider this the final or not.
Another thing, to save you some trouble...;) You will need a compiler which supports 1999 ISO Standard C. The ICL10.1 does.

[James]

Another thing, to save you some trouble...;) You will need a compiler which supports 1999 ISO Standard C. The ICL10.1 does.

Uh-oh. I'm not sure if VS2005 does. :o

[James]

Uh-oh. I'm not sure if VS2005 does. :o

Just tried, it doesn't. :(

[yesgrey3]

Just tried, it doesn't. :(
Let me know what you want to do. Just keep my build linked in this thread and keep the 0.1.4 version with your reclock installer, or remove my build and just forget about 0.1.5...

[James]

Let me know what you want to do. Just keep my build linked in this thread and keep the 0.1.4 version with your reclock installer, or remove my build and just forget about 0.1.5...
I changed the source a little and it compiles with VS2005 (ignoring some warnings). No big deal. I'll release ReClock 1.8.3.1 beta in a second...

[leeperry]

I changed the source a little and it compiles with VS2005 (ignoring some warnings). No big deal. I'll release ReClock 1.8.3.1 beta in a second...
awesome, muchas gracias http://forum-images.hardware.fr/images/perso/bluecactus.gif
After James release his build, let's compare it with the one linked here and if Jame's build is faster I will remove my link. Please post here the compare results.
http://www.djbcompanies.com/ecard/front_image/10/medium/You-Talkin-To-Me-1-of-2.jpg

I'll post my results in a few 8)

[James]

After James release his build, let's compare it with the one linked here and if Jame's build is faster I will remove my link. Please post here the compare results.

I am quite sure your build is faster (using a better compiler). Nevertheless, I'm quite happy with my build. ;)

[leeperry]

ok so I've picked 3 movies, basically yesgrey3's generic O3 build's faster for 6 channels, and it's very close for stereo....maybe James build's a bit faster in that particular case.

but for very high bitrate movies(non h264), yesgrey3's build seems less CPU intensive(better MT management?)...even for stereo :)

***5.1 32float 96KHz ***

movie A / 1.5mbit dts
yesgrey3 : max 25 / sits 22.8
James : max 26.9 / sits 24.9

movie B / 384kb ac3
yesgrey3 : max 24.4 / sits 23
James : max 26 / sits 24

movie C / 1.5mbit dts
yesgrey3 : max 24.5 / sits 23
James : max 26.6 / sits 24.3

***stereo 32float 96KHz ***

movie A / 1.5mbit dts
yesgrey3 : max 16.1 / sits 14
James : max 15.3 / sits 14

movie B / 384kb ac3
yesgrey3 : max 13.7 / sits 13
James : max 14.1 / sits 12.6

movie C / 1.5mbit dts
yesgrey3 : max 15.3 / sits 13.5
James : max 15.1 / sits 13.7

[yesgrey3]

I am quite sure your build is faster (using a better compiler). Nevertheless, I'm quite happy with my build. ;)
I have said this because with 0.1.4 I found that your build was a little faster than mine, but with 0.1.5 it appears that's not the case anymore. No problem, I'm not in a race, I am just looking for the better option.:)

In the next days I will build a new version using ICL11... Let's see if I can defeat myself...:D
leeperry, stay tuned, once again you'll be the judge...;)

[James]

ok so I've picked 3 movies, basically yesgrey3's generic O3 build's faster for 6 channels, and it's very close for stereo....maybe James build's a bit faster in that particular case.

but for very high bitrate movies(non h264), yesgrey3's build less CPU intensive(better MT management?)...even for stereo :)

With MT you mean multi threading/tasking? No way. Better optimized code, that's all.

[James]

I have said this because with 0.1.4 I found that your build was a little faster than mine,
Really? That's a little unexpected.

but with 0.1.5 it appears that's not the case anymore. No problem, I'm not in a race, I am just looking for the better option.:)

In the next days I will build a new version using ICL11... Let's see if I can defeat myself...:D
leeperry, stay tuned, once again you'll be the judge...;)

Are you using any optimization options, like MMX/SSE/SSE2/...? I don't, because I am afraid of broken filters written in assembler, which might stumble if some CPU registers have changed.
Ogo saves/restores all FPU registers, which is very ... scary. It is even mentioned in his changelog.
That aside, I tried the global optimizer and SSE2 in VS2005, and resampler was getting slower. Really weird.

[yesgrey3]

Really? That's a little unexpected.
Not so. My build was with O2 optimizations, and have found with this one that O3 is better. Maybe the previous also was better with O3, but now it's not worth trying it.

Are you using any optimization options, like MMX/SSE/SSE2/...?
That aside, I tried the global optimizer and SSE2 in VS2005, and resampler was getting slower. Really weird.
Haven't you read this thread from start (the SSSE3 version included all SIMDs up to SSSE3)? I have build several versions and the faster was the generic build... I don't think it's weird, maybe it's the code that doesn't need the SIMDs, or that the assembly generated is of poor quality to this kind of code...

[James]

Haven't you read this thread from start (the SSSE3 version included all SIMDs up to SSSE3)?
Obviously not... or I've forgotten... shame on me... :o

[BurnerHEAD]

Quote: Originally Posted by yesgrey3
Another thing, to save you some trouble... You will need a compiler which supports 1999 ISO Standard C. The ICL10.1 does.

Quote: Originally Posted by James
Uh-oh. I'm not sure if VS2005 does.

Just, a note for you James, you ever thought about using VS2008?
IMHO it's a lot better.

Best Regards,
BurnerHEAD

[James]

Just, a note for you James, you ever thought about using VS2008?
IMHO it's a lot better.

No, as executables compiled with VS2008 won't run on Windows 9x/ME and NT4.
Define "a lot better".

[yesgrey3]

Obviously not... or I've forgotten... shame on me... :o
No problem.:D
But the result was funny. It showed us that all this SIMDs obsession should be refrained. It's not a solution for everything, only for the things that it was aimed for...;)

[Jong]

Overall this build is now fantastic. No problem at all using "excellent". I would almost say it should be "recommended" for all but those with antiquated hardware.

One small thing though. Its much less important now, since this build is so much more efficient, but the original ICL10 build (0.1.4?) was clearly multi-core capable. It spread itself nicely across the cores. This build seems to all run on the first core. I liked the old way, although I appreciate it may depend on your CPUs and workload.

[yesgrey3]

but the original ICL10 build (0.1.4?) was clearly multi-core capable.
Can you tell me the date and size (in bytes) of the file?
It's strange, because the code is not multithreaded. The compiler has the possibility of creating some multithreaded parts, but I have disabled all, because, as we have tested, the cpu load was higher.
Remember that MT is not a miracle solution. For some things is great, for others is not. In a quad core cpu, having the resampler MT, even if he uses a little more cpu power, could be good, but in a dual core cpu, is better a faster ST resampler, because the video decoder could run on the other...

[James]

One small thing though. Its much less important now, since this build is so much more efficient, but the original ICL10 build (0.1.4?) was clearly multi-core capable.
No. It may look like this, depending which thread calls ReClock's "RenderSample", and on which core this thread is scheduled.

[Jong]

Well it is possible I was going mad but in late November I was sure (http://forum.slysoft.com/showthread.php?p=148418&highlight=resampler#post148418) that using yesgrey's resampler the resampler load was balanced. I was using this (http://forum.slysoft.com/showpost.php?p=131333&postcount=430)version of resampler and whatever version of Reclock was out at the time. I remember switching between the dlls and getting consistent results.

I can see the point about it sometimes not being good on a dual core, in fact that is what I was referring to at the end of in my previous post. However, it was good for me with the very heavy demands of "excellent" resampling and doing HA accelerated blu-ray playback (very low CPU for video decoding).

But, as I said, it is all less important now anyway given the huge improvement in resampler performance.

[yesgrey3]

James,
Libsamplerate version 0.1.5 was oficially released today. The code is exactly the code I have already released, the 0.1.5pre2, so, no need to release a new build. Can you please update the title of this thread to remove the pre2?

Another thing, do you think it would be a good idea to also put in the title that in this thread is available an ICL version of the resampler? Do as you prefer...

[leeperry]

In the next days I will build a new version using ICL11... Let's see if I can defeat myself...:D
leeperry, stay tuned, once again you'll be the judge...;)
no probs, lemme know http://forum-images.hardware.fr/images/perso/casper87.gif

[shaolin95]

Quick question guys is this still faster than the newer version or Reclock?
Thanks

[yesgrey3]

If it wasn't faster, it would not be available...;)
See post #29 in this thread.

[shaolin95]

Sweet!
You are on a roll with this and of course improving the ddcc thingy. I am actually getting a faster CPU to make sure I got lots of power to keep playing with all this...its more fun that actually watching the movies. :D
If you could take a look at this I would appreciate:
http://forum.slysoft.com/showthread.php?p=165860#post165860
:clap:

[leeperry]

it's more fun that actually watching the movies :D
sure is :D

and I shall add that inputting 32 float from ffdshow to Reclock sounds delightful :agree:

[shaolin95]

on Vista I get some artifacts when I do that though...

[leeperry]

I also had mixed experiences w/ Vista in KS...too many random glitches to my taste, even in 32 integer.

plus I really don't like all these mandatory system services and those ClearType fonts that look blurry to hell :mad:

[shaolin95]

I like how vista looks clearer than xp at least to my eyes and so far the only problem I got is getting some BluRay rips to play the correct audio file.
http://forum.slysoft.com/showthread.php?t=25454
If you got a minute check my post above Leeperry please. :)

[Jong]

So guys, what is the view on the ICL10.1 build versus James' new improved 1.8.3.2 build?!

[noee]

Not sure if it's related or not, but I after upgrading to 1.8.3.2 and FFDshow to ffdshow_rev2618_20090113-mt_sse_icl10,

I get 32 Float working without pops and cracks in Excellent AC3 mode with my RME card, using jRiver MC13 for playback.

Using LSF and HR too. This is a very sweet setup for SD material.

[BurnerHEAD]

No, as executables compiled with VS2008 won't run on Windows 9x/ME and NT4.
Define "a lot better".

Er... who is using Windows 9x/Me and NT4 these days? Nobody.
For AnyDVD you need a DVD Drive or Bluray Drive and in order to get PowerDVD version running you need a lot of system ressources, that no Win9x/Me, NT4 computer can provide.
The oldest system I have running is windows 2000 and that's really not often used. Almost all of my computers and laptops have Vista. Some stay at XP.

Advantages:
- LINQ support
- Nicer looking GUI with WPF-Designer
- better crack protection with .Net Framework 3.5(or any former version)
- you can still choose between .Net Framework 2 or 3 or 3.5 applications

Best Regards,
BurnerHEAD

[yesgrey3]

here is a pack with several ICL11.0 builds and the better ICL10.1 build. Please test it to see which is the winner.

For my cpu, the winner is...
ICL10.1.
It still keeps the crown.:)

Edit: removed the file with the test builds. Already tested by leeperry.

[James]

Er... who is using Windows 9x/Me and NT4 these days? Nobody.


For a small standalone DVD player replacement, e.g. for people like me who hate the PAL speedup, Win 9x with 128MB is fine. An old PowerDVD version is enough.

And yes, AnyDVD, Virtual CloneDrive and ReClock work fine under 9x.

[James]

Advantages:
- LINQ support
- Nicer looking GUI with WPF-Designer
- better crack protection with .Net Framework 3.5(or any former version)
- you can still choose between .Net Framework 2 or 3 or 3.5 applications

Most of our programs are OS drivers / OS extensions / system tools. We don't do .Net.

[leeperry]

here is a pack with several ICL11.0 builds and the better ICL10.1 build.
awesome, thanks! I'll run tests later today :agree:

[leeperry]

well James b32 build is actually not that bad :D

***5.1 32float 96KHz ***

-movie 720p 2.35 23.976@48 / 1.5mbit dts :
Reclock b32 stock: max 24.8 / sits 23.5
Resampler_ICL10.1_O3 : max 24.7 / sits 23.5
Resampler_ICL11.0_O2 : max 24.8 / sits 24
Resampler_ICL11.0_O2_MT : max 24.7 / sits 23.6
Resampler_ICL11.0_O3_MT : max 24.6 / sits 23.6
<<too slow>>
Resampler_ICL11.0_O3 : max 33.3 / sits 33
Resampler_ICL11.0_O3_MT_SSSE3 : max 33 / sits 32

-movie 1080p 1.78 23.976@48 / 1.5mbit dts :
Reclock b32 stock: max 25.4 / sits 24.6
Resampler_ICL10.1_O3 : max 25 / sits 23.8
Resampler_ICL11.0_O2 : max 24.2 / sits 23.4
Resampler_ICL11.0_O2_MT : max 24.1 / sits 23
Resampler_ICL11.0_O3_MT : max 23.7 / sits 23

***stereo 32float 96KHz ***

-movie 720p 1.78 29.97@59.94 / 1.5mbit dts :
Reclock b32 stock: max 15.3 / 12 sits
Resampler_ICL10.1_O3 : max 16.2 / sits 11.5
Resampler_ICL11.0_O2 : max 17.4 / sits 13
Resampler_ICL11.0_O2_MT : max 16.6 / sits 12.7
Resampler_ICL11.0_O3_MT : max 15.8 / sits 12

-movie 720p 1.67(+spline resize) 23.976@48 / 1.5mbit dts :
Reclock b32 stock: max 16.4 / sits 16
Resampler_ICL10.1_O3 : max 16.6 / sits 16
Resampler_ICL11.0_O2 : max 17.1 / sits 16.9
Resampler_ICL11.0_O2_MT : max 17.2 / sits 16.7
Resampler_ICL11.0_O3_MT : max 17.5 / sits 17

-movie 720p 2.35 23.976@48 / 1.5mbit dts :
Reclock b32 stock: max 15.1 / 14 sits
Resampler_ICL10.1_O3 : max 15.5 / sits 14.6
Resampler_ICL11.0_O2 : max 15.6 / sits 14
Resampler_ICL11.0_O2_MT : max 15.1 / sits 13.7
Resampler_ICL11.0_O3_MT : max 15.4 / sits 14.8

-movie 720p 1.78 23.976@48 / 1.5mbit dts :
Reclock b32 stock: max 16.3 / sits 15.9
Resampler_ICL10.1_O3 : max 16.5 / sits 16.2
Resampler_ICL11.0_O2 : max 16.5 / sits 15.3
Resampler_ICL11.0_O2_MT : max 17.1 / sits 15.6
Resampler_ICL11.0_O3_MT : max 16.9 / sits 15.9

[James]

well James b32 build is actually not that bad :D

Amazing. And a little disappointing, I would've expected ICL to perform better.
I've used no processor specific extensions at all.

[James]

Not sure if it's related or not, but I after upgrading to 1.8.3.2 and FFDshow to ffdshow_rev2618_20090113-mt_sse_icl10,

I get 32 Float working without pops and cracks in Excellent AC3 mode with my RME card, using jRiver MC13 for playback.

Using LSF and HR too. This is a very sweet setup for SD material.

32bit float was broken with ReClock versions < 1.8.3.2

[yesgrey3]

Amazing. And a little disappointing, I would've expected ICL to perform better.
I've used no processor specific extensions at all.
Remember that the processor specific extensions does not help with the resampler...;)
Maybe it was the little changes you have made. If you want to show me that changes, I could build the resampler with it and see.
By the way, I think I will keep just the ICL10.1 build. The other builds are not better. Maybe I should remove it completelly and just keep Jame's build, since the performance is almost the same, and sometimes even better... James, what do you think?

[James]

Maybe it was the little changes you have made. If you want to show me that changes, I could build the resampler with it and see.

In ReClock 1.8.3.1's resampler I forgot to enable intrinsic functions. I believe that's the only difference.
The other difference is in the code, because the of C99 incompatibility of VS2005 I needed to use _alloca instead of arrays with variable size, but this change is only for >6 channels which leeperry didn't measure.
If I have the time, I'll post the sources.


By the way, I think I will keep just the ICL10.1 build. The other builds are not better. Maybe I should remove it completelly and just keep Jame's build, since the performance is almost the same, and sometimes even better... James, what do you think?
I think the version included with ReClock is sufficient, the differences in performance are minimal. But you can keep it so people can experiment if they like.

[leeperry]

I've been getting random small glitches lately....the only thing I've changed is updating ffdshow and use the stock resampler :confused:

I will run more tests :)

[noee]

Me too and I just updated ffDshow to the "Q" version with the new "colorspace" conversion.

On my setup, it's complete audio drop out, only on AC3 encoded, 6-channel.

[leeperry]

nah that's cool, for some reason the Sonic 4.2 AC3/DTS decoder makes random glitches in one of its modes....but only on AC3 streams :doh:

[yesgrey3]

libsamplerate was updated to version 0.1.7, just some bugs correction and now it does not need an ANSI C1999 compiler, so it can be compiled by MSVC.
Here is a pack with 5 builds, 2 ICL10.1 and 3 ICL11.0. The ICL11.0_O3_MT is the one which performs better in my computer. Please give it a try and let me know your results, so I can update the first post with the 0.1.7 version.
I also would like to know if any of the ICL11.0 builds sounds better to you, or if all sound equal...
6183

James,
Here is the source so you can update the resampler included in reclock's installer, so we can see if with this new release I recover the lost speed crown...:D
6184

[James]

James,
Here is the source so you can update the resampler included in reclock's installer, so we can see if with this new release I recover the lost speed crown...:D


Thanks, I'll try it out. :bowdown:

[leeperry]

Please give it a try and let me know your results, so I can update the first post with the 0.1.7 version.
I also would like to know if any of the ICL11.0 builds sounds better to you, or if all sound equal...
will do, thanks!
the more it goes, the more I really can't stand resampling, though....I've got new headphones(DT770Pro/250 w/ high end recabling) and resampling now sounds overly bright and distorted :D
so I don't upsample to 96KHz in ffdshow anymore, and avoid winamp2 enhancement plugins whenever possible(Ozone 4 is so good on movies in ffdshow that it's hard to pass up)....ideally a resampler shouldn't make the audio brighter.
the only way to really compare it(considering the brain audio memory is so short) is within ffdshow, can you please make an updated dll for ffdshow ? then I'll try to give my opinion :D
I'll try it out.
OK cool, then I'll compare all the versions at the same time :)
hopefully you can add it in b36?

[leeperry]

ok so I've compared them all on 2 movies, one 5.1 the other in stereo....there are differences, but nothing to write home about...the stock resampler is just fine 8)

that's on an o/c Q6600, w massive avisynth/winamp2 post processing and CoreAVC CUDA

dts 5.1, 48KHz 32float 23.976@48Hz
stock : 14.3 max, 13.5
Resampler_ICL10.1_O3 : 14 / 13.2
Resampler_ICL10.1_O3_MT : 14.1 / 13.2
Resampler_ICL11.0_O3 : 14.3 / 13.1
Resampler_ICL11.0_O3_MT : 14.6 / 13.4
Resampler_ICL11.0_O3_MT_FP : 14.5 / 13.9

stereo, 48KHz 32float 23.976@48Hz
stock : 9.7 / 8
Resampler_ICL10.1_O3 : 13.3 / 9.6
Resampler_ICL10.1_O3_MT : 10.2 / 8
Resampler_ICL11.0_O3 : 10 / 8.7
Resampler_ICL11.0_O3_MT : 9.9 / 8.3
Resampler_ICL11.0_O3_MT_FP : 10.1 / 9

[yesgrey3]

there are differences, but nothing to write home about...the stock resampler is just fine 8)
Have you noticed any difference in sound quality?

[leeperry]

well if I can't A/B, it's virtually impossible to compare them....we're talking about very slight differences, right ?

and why would the compiler mess w/ the SQ :confused:

[yesgrey3]

and why would the compiler mess w/ the SQ :confused:
Because to run faster the compilers have an option to use a slightly less accurate floating point operation mode, with some optimizations to gain speed. The FP version was built using the accurate mode, and I would like to know if is there any difference... but probably the FP optimizations do not affect the sound quality... I will try to test it.

[leeperry]

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

Info
- process: Compare
- source: FP.wav
- reference: O3.wav

Errors
- errors: 0
- warnings: 0
- other: 0

Info
- process: Compare
- source: FP.wav
- reference: MT_FP.wav

Errors
- errors: 0
- warnings: 0
- other: 0

..case closed, NEXT! :D

[yesgrey3]

..case closed, NEXT! :D
Thanks! You saved me some time.;)

[yesgrey3]

leeperry,
Can you test this new resampler.dll I've created, and compare it with the previous release, the resampler2x_b? Let me know which sounds better.
I am trying to understand why you prefer when it resamples to ~96kHz vs ~48kHz...;)
9357

[leeperry]

ah, what did you change?
I already tried to explain why it sounds better..you're better off doing 99.8% upsampling than 0.1% downsampling, it's easier to add data than to remove some...which simply kills the phase linearity and the trebles fidelity.

[yesgrey3]

I will tell you later, just test it and let me know which you prefer.;)

[leeperry]

just test it and let me know which you prefer.;)
alright, I ran some tests :)

first I should state my config test: 5.1 16/48 FLAC in madFLAC > ffdshow audio PP in 32float(5.1>binaural custom matrix downmix) > Reclock in 32float > bit-perfect Prodigy HD2 Advance Deluxe(fit w/ custom op-amps) > MDR-CD3000

in Kill Bill 1 when Beatrix says "by 20, she was one of the top female assassins in the world" at 42'49:
-no resampling: you can clearly hear her mouth noises
-regular resampling: no mouth noises and her voice is noisy and distorted
-"b" 2X resampler: very close to the "no resampling" version, just a tiny bit more distorted, but I really have to be careful to notice it...a far cry from 47952Hz resampling, no contest!
-"c" 2X resampler: it sounds noisier/whinier/more distorted, like some sort of EQ is being used? less bass, more trebles? these might just be resampling artifacts..

I hope I passed, and as the cMp coder says...maybe 192Khz is teh solution :p

[yesgrey3]

alright, I ran some tests
But what is whorse, the regular or the 2x_c?

Before I tell you more details about my findings, I would like you to test these other two resamplers:
9358
9359

Both have a lower volume, the "d" is the same as the regular with a lower volume, and the "e" is the same as the "c" but also with a lower volume. Let me know if with these you hear the same noise and distortion that with the normal volume versions...

[leeperry]

Resampler1x_d.zip = mouth noises are still gone

"b" sounds way better than c/e, sound is just more bassy/less distorted, closer to the original...about whether "e" is better than "d" is complicated, "d" has good bass but mushy trebles, and "e" has a thinner/more distorted sound in the trebles....I pick "b"! and maybe "b" at 192Khz would be even better if you feel like compiling it :D

[yesgrey3]

You asked for...
Here are more two at 192kHz. Let me know which you prefer.
9361
9362

Don't forget to change the registry key. For 192kHz it should be:
"ForceSampleRate"=dword:0002EE00

[leeperry]

very nice, thanks! g sounds better than f, f still has that thinner sound I don't like...one day you'll tell me what it's all about :D

and comparing b against g, I'd go for g :)

when she says "She was one of", the "Sh" sound is full of artifacts in 96KHz...they're still there in 192, but a lot less.

I've done a lot of comparisons, running this sentence in loop in KMP...basically:
*untouched: this sentence has a lot of "depth" like if Beatrix were talking in the same room where I stand(I use LT1364 op-amps that give uber-lively vocals)
*48KHz: the trebles are completely mushed and the sound is like a 192kbit MP3
*96Khz: it's better but still sibilating
*192KHz: it's much better, still sibilating(as any resampling increases distortion)...it loses some of the "room" ambience of the studio cabin where that sentence was recorded, but it's the best I've heard so far :agree:

still makes me crave for 47.952Hz w/ no resampling....too bad ogo chose libsamplerate over libavcodec(that seems to sound clearer and less sibilating) :o

and my board runs an AK4396 that does 128X oversampling up to 192Khz, but for instance the PCM1792A only does 64X above 96KHz...so YMMV.

[Mark_A_W]

I reckon you guys need a thread just for this purpose.


It sure as hell aint bit-exact with no resampling ;)

[yesgrey3]

Yes, I agree, this discussion is completelly off-topic.

leeperry, maybe it's better you to create a new thread for this discussion, and let's hope that James could remove some of the posts here and put them in the new thread...

[yesgrey3]

we've always been discussing resampling in this thread, I dunno what's up w/ you ppl.
Just this little thing (thread title):
"Bit exact audio in Reclock without any resampling";)
Please create a new thread, about oversampling, that will also attract more people. Who would think that oversampling is being discussed in a thread about reclock without any resampling?:D
Let's hope James can move the posts from here to there...

[yesgrey3]

It seems the new thread does not appear, so, after all these posts, one more will not make it worse...

Here is a decription of the several resamplers:
resampler2x_b: same as regular resampler, but resamples to 2x the source sampling rate
resampler2x_c: resamples to 2x the source sampling rate, but the code added to decrease the volume in case of overload was removed
resampler2x_d: same as 2x_b but with a lower volume, to guaranty no overloads
resampler2x_e: same as 2x_c but with a lower volume, to guaranty no overloads
resampler2x_f: same as regular resampler, but resamples to 4x the source sampling rate
resampler2x_g: resamples to 4x the source sampling rate, but the code added to decrease the volume in case of overload was removed

So, leeperry, is strange that at 2x you prefer the 2x_b compared to the 2x_c and then at 4x you prefer the 4x_g to the 4x_f.

What was my idea?
When in a digital signal the maximum available value is reached, we cannot know if we are in the presence of an overload or not. It could simply be the highest value of the signal, or it could also be a value below that. In the first case, there is no problem, no distortion is added, but in the second case, don't.
When we oversample a signal like in the second case, some of the new samples could be outside of the valid range. There, if we disable the code that corrects that by lowering the volume proportionally, the distortion would be higher, and this would affect particularlly the higher frequencies. So, when leeperry first said that he prefered the 2x_b, it was possible that it could be caused by an overload. Later, when he prefered the 4x_g, it showed that cannot be an overload problem (it was a bit strange that in a dialog existed any overload, but who knows?...)
In any case, I have found one more good reason to add the possibility of oversampling to reclock: help to avoid the overloads that could exist in the original signal.;)
If you want to read more about this subject, see here (www.tcelectronic.com/media/nielsen_lund_2000_0dbfs_le.pdf), or google about "loudness war".

I hope I was clear enough, but I only have learned this in the past two days, so it's all still very new to me...

[leeperry]

well, I'm apparently known to be an everlast whiner for invisible things on doom9...or so I was told a fews days ago :D

so I prefer to whine in existing threads than creating new ones...let's discuss it there then, I took your wrong thread by mistake: http://forum.slysoft.com/showthread.php?t=24236&page=2

[leeperry]

It seems the new thread does not appear, so, after all these posts, one more will not make it worse...

Here is a decription of the several resamplers:
resampler2x_b: same as regular resampler, but resamples to 2x the source sampling rate
resampler2x_c: resamples to 2x the source sampling rate, but the code added to decrease the volume in case of overload was removed
resampler2x_d: same as 2x_b but with a lower volume, to guaranty no overloads
resampler2x_e: same as 2x_c but with a lower volume, to guaranty no overloads
resampler2x_f: same as regular resampler, but resamples to 4x the source sampling rate
resampler2x_g: resamples to 4x the source sampling rate, but the code added to decrease the volume in case of overload was removed

So, leeperry, is strange that at 2x you prefer the 2x_b compared to the 2x_c and then at 4x you prefer the 4x_g to the 4x_f.

What was my idea?
When in a digital signal the maximum available value is reached, we cannot know if we are in the presence of an overload or not. It could simply be the highest value of the signal, or it could also be a value below that. In the first case, there is no problem, no distortion is added, but in the second case, don't.
When we oversample a signal like in the second case, some of the new samples could be outside of the valid range. There, if we disable the code that corrects that by lowering the volume proportionally, the distortion would be higher, and this would affect particularlly the higher frequencies. So, when leeperry first said that he prefered the 2x_b, it was possible that it could be caused by an overload. Later, when he prefered the 4x_g, it showed that cannot be an overload problem (it was a bit strange that in a dialog existed any overload, but who knows?...)
In any case, I have found one more good reason to add the possibility of oversampling to reclock: help to avoid the overloads that could exist in the original signal.;)
If you want to read more about this subject, see here (www.tcelectronic.com/media/nielsen_lund_2000_0dbfs_le.pdf), or google about "loudness war".

I hope I was clear enough, but I only have learned this in the past two days, so it's all still very new to me...
well, my comparisons were honest...but placebo is very real.

anyway I've just watched a 23.976fps@96Hz movie w/ the 4X "g" oversampler and mVR....well, let's just say that my whining might have come to an end :D

lossy DTS sounds bad(avoid libdts, it's terrible), resampling kills the SQ...but I think this is as good as it's gonna get, as you can't quite get smooth playback at the right speed w/ untouched audio(on a board that runs an AK4396 w/ swappable op-amps ;))

mVR is amazingly smooth in 96Hz on my CRT in KMP, not a single dropped frame, the stereo phase was perfect, and the trebles very clear..and your resampling in 192KHz in KS was flawless too, no glitches whatsoever!

Kazuya said he had some random dropped frames in 50Hz so I'll try some movies in 48Hz on my DLP pj in the next coming days....but in 96Hz mVR 0.11 is totally flawless, such a relief to drop HR and its stinky jitter(that completely put me off watching movies :mad:)

BTW, The Mothman Prophecies is a great little movie.

PS: when James will have added oversampling, maybe I can try again...

[yesgrey3]

well, my comparisons were honest...but placebo is very real.
I never doubted that, but yes, it could be a little placebo effect.;)

avoid libdts, it's terrible
So, what do you suggest? And for AC3?

but I think this is as good as it's gonna get, as you can't quite get smooth playback at the right speed w/ untouched audio(on a board that runs an AK4396 w/ swappable op-amps ;))
You can always buy a RME FF800, open it, and swap the op-amps.:D

[leeperry]

well, I like the "g" resampler in 192KHz, the phase and the trebles are as good as it's gonna get :)

for AC3, I like liba52 in ffdshow...it decodes in 32float and the AC3 specs are well known.

the problem w/ libdts is that it's been reversed engineered and never updated due to DTS legal threats I think? it sounds terrible....the dialogs are hissy/distorted, ugly!

libavcodec sounds a heck better, too bad it's 16int only(DTS is 18/19bit natively)...I personally got a hook for Sonic 4.2, but you can't completely disable DRC.

I'd advise AC3Filter(in 32float) if you don't need to make autoload profiles in ffdshow, as it's broken at this point...so I can't use it :bang:

hehehe, it sounds a bit pricey to open a brand new FF800 to swap the op-amps, I have the feeling that these "pro" brands ask for a premium because the market is willing to pay extra for lotsa exotic I/O and very powerful routing in the drivers...but the hardware part is nothing to write home about..most of the RME cards use JRC4580, which is very nice for driving headphones...but lacks the transparency of the LT1364 on vocals, or the audiophile mids/natural soundstage of the OPA2132 ;)

I will prolly try to replace my OPA2132P buffer by a Burson op-amp, these are just out of this world I was told..

[yesgrey3]

I'd advise AC3Filter if you don't need to make autoload profiles in ffdshow
I don't, so I will try AC3Filter... Is it as good as liba52 for AC3?

but the hardware part is nothing to write home about.
That's not true. Maybe the opamps are not very high quality, but the dacs are and the clock circuits too. They have jitter < 1ns, and this should be way more significant for the sound quality than the opamps... ;)
Since my FF400 is already out of warranty, maybe one day I will be crazy enough to open it and swap the opamps.:D

[leeperry]

I've never really compared liba52 against AC3Filter(in 32float), but the AC3 specs are public...the problem w/ DTS is that they are not..

yes ok, that's true...they have good clocks indeed, very nice for S/PDIF or AES/EBU transmissions.

well, you'd simply need to put adapters, and get rolling: http://cimarrontechnology.com/dip8toso8adapterpn031101b.aspx

[yesgrey3]

the problem w/ DTS is that they are not.
Have you ever tryed converting a dts soundtrack to flac using eac3to? That way you can decode using official decoders.;)
yes ok, that's true...they have good clocks indeed, very nice for S/PDIF or AES/EBU transmissions.
And also for the digital to analog conversion... The clock is one of the most important things for you to be able to recover the original analog sound. The samples need to be in the right place in time, not before, nor after.;)

[leeperry]

well, I had the problem w/ DTS 96/24...the Arcsoft decoder can decode it in a DS player, but it always reverts to stereo output by default...it's most likely embedded in the IPersistStream interface, but no media players cares about this :rolleyes:

yeah true! but it all depends on the DSP jitter itself, the Asus STX>ST have a different clock...but their crappy CMI8788 DSP has a 750ps jitter spec, so any clock improvement is totally pointless :doh:

[briands]

You asked for...
Here are more two at 192kHz. Let me know which you prefer.
9361
9362

Don't forget to change the registry key. For 192kHz it should be:
"ForceSampleRate"=dword:0002EE00

This is starting to sound like an eye exam... :)

[yesgrey3]

This is starting to sound like an eye exam... :)
I would say more like an ear exam...:)

[yesgrey3]

I'd advise AC3Filter(in 32float)
I've looked into it but AC3Filter is also based on libdts.:(
So, probably it seems the better option is ffdshow with libavcodec...

[Mark_A_W]

DTS is so '90s.

DTS-HD MA is where it is now ;)


Who cares about subtle (inaudible...) differences in a lossy compression method....

[leeperry]

I would say more like an ear exam...:)
hehe, my otologist hides when he sees me :D
Who cares about subtle (inaudible...) differences in a lossy compression method....
very audible yes, libdts in ffdshow is unbearable on dialogs :disagree:
I've looked into it but AC3Filter is also based on libdts.
O RLY? I couldn't find the info...got a link? anyway AC3Filter is buggy for DTS apparently : http://forum.doom9.org/showpost.php?p=1334298&postcount=17

anyway, it's funny how everything has a role to play in PC audio...I just ditched my BeQuiet 500W for a Corsair 400W, because it gave the lowest ripple measurements on both a french specialized site and anandtech...and the SQ is just miles better!

http://translate.google.com/translate?u=http%3A%2F%2Fwww.canardpc.com%2Fdossie r-36-450-Corsair_CX_400_Watts.html&sl=fr&tl=en&hl=en&ie=UTF-8

wider soundstage, clearer trebles, better stereo imaging...we're basically listening to the 220V current, so better transform it to 12/5/3.3V w/ the lowest ripple.

some guys on head-fi have made stabilized PSU's for their Asus STX, they get 0.1mV ripple....man, the SQ must really be as good as they say...too bad Asus is the only company making soundcards w/ a separate molex plug, and that their C-Media drivers suck monkeys ***** :/

[yesgrey3]

DTS is so '90s.
DTS-HD MA is where it is now ;)
Yes, but sometimes only dts soundtracks are available...
Maybe I will decode them to flac with eac3to.;)

O RLY? I couldn't find the info...got a link?
No need. Just go to the AC3Filter About tab and see the "Thanks to" group.

anyway, it's funny how everything has a role to play in PC audio...
Another point to my FF400, with its own power supply...:)

[leeperry]

Yes, but sometimes only dts soundtracks are available...
Maybe I will decode them to flac with eac3to.
no need, use Arcsoft's DTS decoder..done :)
Another point to my FF400, with its own power supply...
..which is a wall wart? it's got very nasty ripple. Sure, they can stabilize it w/ a proper power stage on the PCB, and I sure hope they do for the price they're asking :p

I would even dare to say that the P5K Premium sounds clearer than my previous GA-P31-DS3L(cheapo as can be)...it's got a killer PCB w/ very low ripple/crosstalk. Asus are the leaders when it comes to PCB shielding, there's no contest.

I've never been into spending a lot into mobos, but a $300 mobo gives a better SQ than a $60...God forbid, ground shielding is an art :policeman:

my next(last?) upgrade will be a burson op-amp as the last buffer, these things are mind blowing from what everyone says: http://www.bursonaudio.com/opamp101.htm

upgraditis is a nasty sickness, each time SQ improves...your previous config becomes instantly unbearable :disagree:

[leeperry]

Reclock b50 is quite a CPU hog w/ 192kHz resampling, and I now have a CPU that supports new instructions(3.5Ghz Q9450 > SSE4.1)...it's time to rerun tests w/ the different ICL versions I think :agree:

[James]

Reclock b50 is quite a CPU hog w/ 192kHz resampling, ....

... and the audio buffers within ReClock are really getting huge. Come on, *you* wanted this! So, no complaining, please. :D How about using 96 kHz? That was the original plan, wasn't it? And - to be honest - I don't hear a difference... :o

[leeperry]

... and the audio buffers within ReClock are really getting huge. Come on, *you* wanted this! So, no complaining, please. :D How about using 96 kHz? That was the original plan, wasn't it? And - to be honest - I don't hear a difference...
huge? like RAM usage?

oh I'm far from complaining, mind you...I knew that 3.5Ghz Q9450 would come in handy someday :D

I've used my best sounding movie(french "GO FAST" BD, the lossless track is simply eye popping like nothing I've heard before :agree:), 88.2 is ugly...176.4 even worse I think, 96 is nice but I think I still prefer 192..I'll compare again, the WaveSpectra measurements show that 96 should be theoritically better, but maybe my DAC and/or audio drivers give better filtering at 192(one of the strengths of the AK4396 DAC).

anyway 96 and 192 offer a much clearer stereo image that 47952Hz...pretty HUGE difference :clap:

[James]

anyway 96 and 192 offer a much clearer stereo image that 47952Hz...pretty HUGE difference :clap:

I'm glad you're happy. And I have to trust your words, as I can't hear a difference... :rolleyes:

[leeperry]

I can't hear a differenceput some AD797B op-amps on whatever soundcard you have, get some nice headphones/speakers and you'll hear it I promise :rock:

[James]

put some AD797B op-amps on whatever soundcard you have, get some nice headphones/speakers and you'll hear it I promise :rock:

No sound card, no op-amps. I use digital out via HDMI. And 192 kHz does work with the Onkyo, it didn't with the Denon.

[leeperry]

there's got to be op-amps in the amps...and usually, pretty generic ones like 5532's..you wouldn't regret swapping them for AD797B ;)

[James]

there's got to be op-amps in the amps...and usually, pretty generic ones like 5532's..you wouldn't regret swapping them for AD797B ;)

No, I'm not swapping the op-amps in the amps... ;)

[leeperry]

No, I'm not swapping the op-amps in the amps... ;)
well, if you can't hear a diff between 47952 and 192kHz, I think you should keep it in mind when the warranty runs out ;)

AD797B is pretty much the best op-amp money can buy: http://www.head-fi.org/forums/f6/audio-gd-discrete-op-amps-reviewed-OPA-earth-OPA-moon-OPA-sun-v-2-a-397691/
2x AD797BRZ – this is the op-amp truly deserving the name of the Analog Device. This one is a smoother and fuller sounding version of the AD797. Switching from the ANZ to the BRZ series is like going vinyl instead of digital. Everything is smooth to the moment your music craves for the harsh texture like aggressive violin passages, distorted guitars, or stronger double bass phrases. The readability of the furthest plans is great, without going into image sharpening effect which makes you see the details more but lose the feeling of perspective at the same time. Roughly, it's like the AD79ANZ with all advantages of the OPA627BP added. The soundstage is nowhere limited and the sound image of whatever possible shape. This is a reference integrated op-amp for me so let me know as soon as you find better, and I will verify it.
I've put 4 of them on my card, and they're not going! :D

http://thumbnails18.imagebam.com/5963/cd268f59626197.gif (http://www.imagebam.com/image/cd268f59626197)

[leeperry]

humm, I think I'm gonna ditch the burson...all I need is four AD797BN, they are totally uncolored and completely versatile soundstage-wise...the only chip I've heard so far that offers so much(for such a low price :eek:)

anyway, what this guy says matches what I'm hearing at 192kHz in Reclock: http://www.head-fi.org/forums/f133/bit-depth-sampling-frequency-explained-455688/index2.html
I can not stress enough that Nyquist assumes an ideal low-pass filter in order to remove the sampling artifacts that are mirrored in the spectrum. Increasing the sample rate allows you to use a much better filter with a more gentle roll-off which avoids putting oscillation and ringing in the audio spectrum.
it also matches what the cPlay coder wrote in his tutorial: http://photos.imageevent.com/cics/v03theartofbuildingcomputertrnsp/The%20art%20of%20building%20Computer%20Transports% 20v0.3.pdf
http://thumbnails6.imagebam.com/5480/889a7d54790781.gif (http://www.imagebam.com/image/889a7d54790781)
and my AK4396 DAC is known for its excellent post-filtering...so going 192kHz increases aliasing, but it can easily filter it out w/ its 128X oversampling: http://www.6moons.com/audioreviews/modwright3/transporter_2.html
Being AKM's flagship part, this DAC has up to 10 times less out-of-band noise compared to anything similar on the market today. It also has the capability to accept a 216KHz sample rate while keeping the same digital filter oversampling rate and the same speed of the modulator."

the Burr-Brown PCM1972A(used on many cards including the Asus Xonar Essence) cannot do 128X oversampling at 192kHz, only 64X.

I can't really picture myself upsampling to 192kHz on purpose, but it's a necessary evil in Reclock anyway.

I see many ppl on doom9 craving for HD audio pass-through via HDMI...but what is the point? get killer SQ and stuttering video? who wants that exactly? "oh my...SQ kicks ass, and I love 60Hz judder too!"

PS: some food for thoughts: http://books.google.com/books?id=VZw6z9a03ikC&printsec=frontcover&dq=Principles+of+Digital+Audio#v=onepage&q=&f=false