[SOLVED] Help with resampling files, I can hear differences between 192/24 and 48/24 ABX tests

[zareliman]

 
no no it's not about the ultrasounds we hear, what we need isn't the ultrasound data, what we need is the resolution to have at least 2 points to create a 22khz signal. so we need at least 44khz of bandwidth to get 2 samples of 22khz per period. if we had only 22khz sample rate, we could only get 1 sample per period of a 22khz signal and thus fail to reconstruct it. (like being asked to draw only one line crossing 2 points. if you have only 1 point you can no longer know which is the right line). 
so we need the higher sampling rate, not higher frequency music.
 
and ABX can of course be cheated, that's why we suggest using the same resolution for both tracks but upsampling back,  to limit the differences in timing. but in the end a guy who wishes to pass an abx can pass it, just open some spectrum showing if there is or not some ultrasound content and you pass anything without even listening. but we hope that people are looking for answers, not to behave like idiots.

 
Even if you upsample back the "lossy" track the ABX test is flawed because:
Let's say A is X and B is Y. Then when you're switching back and forth from A to X and A to Y, switching from A to X is near instant while swiching from A to Y takes more than 0.05sec (which you can notice). This can be easily fixed to, the script could take the 2 original files and actually duplicate them so the system actually has to load a new file when you switch between the 2 similar audio files (maybe I'll search the developer to suggest that feature).

 

[arnyk]

   
Even if you upsample back the "lossy" track the ABX test is flawed because:
Let's say A is X and B is Y. Then when you're switching back and forth from A to X and A to Y, switching from A to X is near instant while swiching from A to Y takes more than 0.05sec (which you can notice). This can be easily fixed to, the script could take the 2 original files and actually duplicate them so the system actually has to load a new file when you switch between the 2 similar audio files (maybe I'll search the developer to suggest that feature).

 
Your ABX Comparator is obviously defective. The official AES ABX comparator design inserts the same programmed delay into every transition, to avoid exactly this problem.
 
http://www.aes.org/e-lib/browse.cfm?elib=3839
 
The generally accepted tool for this purpose is FOOBAR2000 with the 2.0 ABX plug in.

 

[dbobb]

   
Even if you upsample back the "lossy" track the ABX test is flawed because:
Let's say A is X and B is Y. Then when you're switching back and forth from A to X and A to Y, switching from A to X is near instant while swiching from A to Y takes more than 0.05sec (which you can notice). This can be easily fixed to, the script could take the 2 original files and actually duplicate them so the system actually has to load a new file when you switch between the 2 similar audio files (maybe I'll search the developer to suggest that feature).

Did you try upsampling the downsampled file? It is a known issue with foobar2000 that comparing files with different formats (e.g. sample rates) may lead to different switch times. Try it. Also, you can find the foobar2000 developer, even with a special forum for it, at hydrogenaud.io
Good luck. 
Also, were you satisfied with the Nyquist stuff? It can be confusing math, but there are intuitive explanations... (e.g. slow-appearing wagon wheels in old movies)... no time now, but I can elaborate if you wish, later.
 

   
Your ABX Comparator is obviously defective. The official AES ABX comparator design inserts the same programmed delay into every transition, to avoid exactly this problem.
 
http://www.aes.org/e-lib/browse.cfm?elib=3839
 
The generally accepted tool for this purpose is FOOBAR2000 with the 2.0 ABX plug in.

Did you read the thread? It's not that long yet. He's not using the hardware ABX Comparator. In the OP, he shows he's using foobar2000 v1.3.9 beta 1
with the foo_abx 2.0.1 plugin.

 

[zareliman]

  Did you try upsampling the downsampled file? It is a known issue with foobar2000 that comparing files with different formats (e.g. sample rates) may lead to different switch times. Try it. Also, you can find the foobar2000 developer, even with a special forum for it, at hydrogenaud.io
Good luck. 
Also, were you satisfied with the Nyquist stuff? It can be confusing math, but there are intuitive explanations... (e.g. slow-appearing wagon wheels in old movies)... no time now, but I can elaborate if you wish, later.

Thanks for your explanations, I'll look further into it myself (It's been a while since I don't go into this kind of math but looks fun).
 
I'm very curious about this subject since there's a paper where subjects could tell 96kHz streams from 96kHz with the ultrasound filtered (statistically significant).
Assuming the test was well made that would mean either 2 things:
- Even if you can't "hear" the ultrasounds you can percieve them somehow (it would be interesting to know if the subjects were using headphones or speakers).
- The effect of the ultrasounds in the audible range can be perceived (This still doesn't mean it sounds "better" with the ultrasounds, just more accurate).
There's this other post where they're discussing this, maybe we should go there.

BTW even if you ABX compare 2 files equal in format, sample rate and bitrate (even duplicate files) there's a delay when you switch different streams which doesn't happen when you happen to switch to the same stream. The problem is that the script loads the file in one case but doesn't in the other, which could be fixed by forcing it to always reload the file.

 

[arnyk]

 He's not using the hardware ABX Comparator. In the OP, he shows he's using foobar2000 v1.3.9 beta 1
with the foo_abx 2.0.1 plugin.

 
Hardware ABX Comparators are not necessary for smooth switching or controlled switchover delays.
 
For example the original Software ABX Comparator PCABX had an adjustable switchover time adjustment.
 
However, it is very easy to minimize these effects by ensuring that the files being compared are recorded at the same sample rate. It is very straightforward to record a low sample rate file at a higher sample rate. The losses due to the lower sample rate are represented at the higher sample rate with a high degree of effectiveness.

 

[arnyk]

  Thanks for your explanations, I'll look further into it myself (It's been a while since I don't go into this kind of math but looks fun).
 
I'm very curious about this subject since there's a paper where subjects could tell 96kHz streams from 96kHz with the ultrasound filtered (statistically significant).
Assuming the test was well made that would mean either 2 things:
- Even if you can't "hear" the ultrasounds you can percieve them somehow (it would be interesting to know if the subjects were using headphones or speakers).
- The effect of the ultrasounds in the audible range can be perceived (This still doesn't mean it sounds "better" with the ultrasounds, just more accurate).
There's this other post where they're discussing this, maybe we should go there.

 
Ultrasonics in  music files can have strong audible effects below 20 KHz due to nonlinear distortion in the recording or playback process.  It is a simple matter to detect this problem by means of listening tests involving audio files that are specially recorded to make these kinds of problems very audible.