I'm looking to undertake several ABX tests across multiple participants in a short study, but am coming up short finding actual high-definition samples.
Spectral analysis of tracks I've acquired from HDTracks and other free-to-distribute sources have spectograms like these:
1. I've interpreted this as likely a Redbook CD quality source which has been upsampled.
(https://i.imgur.com/qSIoXRc.jpg)
2. And this one as a 96kHz source which has had some hijinx applied, explaining the high-frequency noise with nothing in the middle.
(https://i.imgur.com/HJTLi3z.jpg)
Could anyone please comment on the above, in particular whether they think I've misread these spectograms?
I would also appreciate if if anyone could direct me towards a genuine sample with high frequency content, suitable for this ABX testing, as I've so far come up empty. Even if these frequencies are patently inaudible, I need to give them a fair crack of the whip for the sake of fairness/good science. :))
Many thanks!
2. Maybe it was converted from DSD?
Second one looks like noise shaping. I don't think it's DSD, there would be more extreme noise shaping and at much lower frequencies.
I think low pass filtering as in #2 is common, if you have too much high frequency energy you can get imd. What are you hoping to test? Sampling rates? The effect of ultrasound? Both?
Second one looks like noise shaping. I don't think it's DSD, there would be more extreme noise shaping and at much lower frequencies.
I think low pass filtering as in #2 is common, if you have too much high frequency energy you can get imd. What are you hoping to test? Sampling rates? The effect of ultrasound? Both?
I'm hoping to do an ABX test of 44.1 with 96/192kHz.
2. Maybe it was converted from DSD?
Look at the upper spectrum pattern carefully, especially somewhere after 7:00.
Looks like aliasing/mirroring/imaging to me.
I see changes in intensity, but not the type of changes in frequency that one would expect to be caused by aliasing/imaging.
If it helps, here is a link (http://www.lindberg.no/hires/test/2L-056_04_stereo_192kHz.flac) to the (freely distributable) sample of the second track. Does this look like 192kHz to you guys? I'm not sure how to interpret the Audacity spectrals/Spex results.
Does anyone know of an audio file (perhaps electronically generated for testing purposes) which includes the necessary frequencies up to 192kHz?
Many thanks.
The 2nd was originally recorded in DXD (352.8k 32bit, presumably with Pyramix) It is noise shaped with the noise rising above the original recording somewhere about 50k (at least in the sections I looked at.) All of the other resolutions at 2L.no's test page are also derived from DXD recordings.
Yes. 2L has a lot of samples up to DXD.
http://www.2l.no/hires/
But as long as they are acoustic recordings, very high frequencies are usually pretty weak and blended with the noise floor. In case you want to use 2L's samples, downsample the hi rez files to redbook yourself instead of using their files. Reason:
https://hydrogenaud.io/index.php/topic,111416.0.html
Generating a synthetic signal with a lot of HF is easy, but... are your participants self proclaimed audiophiles? They may not like this idea as it is not "real" stuff.
Generating a synthetic signal with a lot of HF is easy, but... are your participants self proclaimed audiophiles? They may not like this idea as it is not "real" stuff.
No, it's a lay audience. Do you guys know of any synthetic high-resolution electronic tracks? I've come across several which appear to be 44.1kHz upsampled (as per the first spectrogram above).
But as long as they are acoustic recordings, very high frequencies are usually pretty weak and blended with the noise floor. In case you want to use 2L's samples, downsample the hi rez files to redbook yourself instead of using their files.
Is there a preferred way of converting from DXD to PCM for 192/96/48/44 comparisons, given that the 192kHz samples on that page already seem heavily shaped/have strange high-frequency bands?
No, it's a lay audience. Do you guys know of any synthetic high-resolution electronic tracks? I've come across several which appear to be 44.1kHz upsampled (as per the first spectrogram above).
If you don't even need music... check the attached file.
Is there a preferred way of converting from DXD to PCM for 192/96/48/44 comparisons, given that the 192kHz samples on that page already seem heavily shaped/have strange high-frequency bands?
Resamplers like SoX and SSRC and many others will filter those noise, no special treatment needed.
Is there a preferred way of converting from DXD to PCM for 192/96/48/44 comparisons, given that the 192kHz samples on that page already seem heavily shaped/have strange high-frequency bands?
I suggest modified SoX by mansr at GitHub (https://github.com/mansr/sox)
Graph 2 may be the noise of a recent SDM ADC that operates at higher frequency and is multibit instead of the DSD64 you used to have seen.
As quoted from our DSD decoder help file:
DSD has a sample rate of 2.8MHz, known as D64, or 5.6MHz (D128), but only 1 bit, which creates high frequency ultra sonic noise when decoded to 352KHz, or 704KHz. In-fact it is our understanding that SACD players are recommended to have a low-pass filter of 50KHz to filter out this high frequency noise (you cannot hear it, but your cat or dog might, also the tweeters on the speakers might run hot from it). By using 96KHz this noise is pretty much filtered. It is possible to decode to any number of frequencies, anything above 96KHz should use a low pass filter (DSP effect), ideally set to 48KHz.
Is there a preferred way of converting from DXD to PCM for 192/96/48/44 comparisons, given that the 192kHz samples on that page already seem heavily shaped/have strange high-frequency bands?
I suggest modified SoX by mansr at GitHub (https://github.com/mansr/sox)
Ops! I did misread DXD for DSD somehow. For DXD that is simple PCM use whatever you want. No modified SoX needed.
If you don't even need music... check the attached file.
Unfortunately, given the broader experiment this is a part of, it would need to be music. It's not particularly important what kind, though. :)
I suggest modified SoX by mansr at GitHub (https://github.com/mansr/sox)
Is there a compiled version of Mansr's version? Unfortunately, I haven't the programming expertise to compile this.
To your later post: Is DXD not a container for DSD?
As quoted from our DSD decoder help file:
DSD has a sample rate of 2.8MHz, known as D64, or 5.6MHz (D128), but only 1 bit, which creates high frequency ultra sonic noise when decoded to 352KHz, or 704KHz. In-fact it is our understanding that SACD players are recommended to have a low-pass filter of 50KHz to filter out this high frequency noise (you cannot hear it, but your cat or dog might, also the tweeters on the speakers might run hot from it). By using 96KHz this noise is pretty much filtered. It is possible to decode to any number of frequencies, anything above 96KHz should use a low pass filter (DSP effect), ideally set to 48KHz.
Very interesting to know, thank you for that information. Does this mean that most music recorded in ultra-high resolution DSD (e.g. 704kHz) has the bulk of its higher resolution (>50kHz) content stripped away by filtering?
DXD is 24bit/384kHz PCM. The term was introduced for recordings done in DSD but for processing or distribution converted to this high bitrate PCM.
Very interesting to know, thank you for that information. Does this mean that most music recorded in ultra-high resolution DSD (e.g. 704kHz) has the bulk of its higher resolution (>50kHz) content stripped away by filtering?
http://www.merging.com/uploads/assets/Merging_pdfs/dxd_Resolution_v3.5.pdf
"DXD is defined as a 24-bit signal sampled at 352.8kHz"
You can read the whole pdf and get more information.
DXD is PCM. So just use any popular resampler with good reputation. 2L didn't filter those noise, why should you? I just complained they didn't carefully time align different files, but not other things.
The whole thread should have nothing to do with DSD. While DSD is hi-res, non-DSD doesn't mean non hi-res. In 2L's samples, if it specifies DXD is the source of recording, unless you choose to test the DSD files, it has nothing to do with DSD at all.
http://www.merging.com/uploads/assets/Merging_pdfs/dxd_Resolution_v3.5.pdf
"DXD is defined as a 24-bit signal sampled at 352.8kHz"
You can read the whole pdf and get more information.
Absolutely correct. Not my day today, i better stop posting here.
While DSD is hi-res, non-DSD doesn't mean non hi-res.
Non-DSD but still hi-res should also include CDDA.
While DSD is hi-res, non-DSD doesn't mean non hi-res.
Non-DSD but still hi-res should also include CDDA.
In terms of transparency, I agree with you. But I would take it as a marketing buzzword:
http://ws.sel.sony.com/PIPWebServices/RetrievePublicAsset/StepID/SEL-asset-459151
Why give the term away so freely...
...especially to an unscrupulous corporation?
I don't give a rat's ass about a stupid logo, but is the term trademarked or something?
I don't know. But there are non-Sony products using that logo.
Hardware:
http://archimago.blogspot.hk/2017/05/measurements-smsl-idea-usb-dac.html
Software (hi-res songs)
http://mora.jp/etc/highreso?cpid=leftbannerB
Unfortunately, given the broader experiment this is a part of, it would need to be music. It's not particularly important what kind, though. :)
Chiptunes must be music, right?
http://www.foobar2000.org/components/view/foo_gep
I don't know if you familiar with these stuff or not, the plugin emulates the sound of old game consoles, and you need to find the chiptunes files yourself. You can render the output to any sample rate you like, but for ABX, don't render files at different sample rates separately because it may create differences below 20kHz. You should render at your highest target (e.g. 192kHz) and downsample it to 44kHz for example.
NSF (Nintendo) and HES (PC-Engine) formats are good choices for your test.
Most of the chip formats supported by foo_gep low pass filter at hard configured rates, depending on the sample rate and on the console being emulated.
Here is a way to simulate having ultrasonic hearing with extreme sample rate tracks: (I just downloaded "Vision of Her" in 24/88 FLAC from https://www.oppodigital.com/hra/dsd-by-davidelias.aspx )
sox original.wav shifted.wav pitch -2400 sinc 5k
This pitch-shifts down by 2 octaves (2400 cents), then applies a highpass filter at 5kHz. So, the 20-40kHz range is shifted down one octave to 10-20kHz, then another octave to 5-10kHz. The highpass filter at 5kHz then cuts off everything that was below 20kHz in the original recording.
More fun (?) than staring at Spek spectrograms and wondering what the ultrasonics might sound like if you could hear them.
Most of the chip formats supported by foo_gep low pass filter at hard configured rates, depending on the sample rate and on the console being emulated.
You made it so you must know it :))
SQNY approved hi-res HES attached. 7z compressed better than flac for this file.
But your plugin only allows up to 96k sample rate, so disqualified.
Many thanks for your help, guys. :D
But your plugin only allows up to 96k sample rate, so disqualified.
Not only that, but it renders at 16 bit precision, always, so it's not really hi-res, either.
Not only that, but it renders at 16 bit precision, always, so it's not really hi-res, either.
How about Emu de MIDI?
Not only that, but it renders at 16 bit precision, always, so it's not really hi-res, either.
How about Emu de MIDI?
The MIDI plug in does seem to do 32-bit floating point internally. I doubt you'll find a soundfont that actually has samples sampled at 192 KHz. Not sure about VSTs as much but they're probably similar with their own samples.
Emu de MIDI. This is probably something emulated at one sample rate natively then resampled to whatever the user wants.
The MIDI plug in does seem to do 32-bit floating point internally. I doubt you'll find a soundfont that actually has samples sampled at 192 KHz. Not sure about VSTs as much but they're probably similar with their own samples.
Emu de MIDI. This is probably something emulated at one sample rate natively then resampled to whatever the user wants.
That's unimportant as sf2 are often not chromatically sampled, and it allows up to 2 octaves pitch shift. But I was not talking about SoundFont synth in my previous post as the plugin is quite aliased.
https://hydrogenaud.io/index.php/topic,87639.msg803861.html#msg803861
Would like to see how kode54 thinks about Emu de MIDI. I'd consider aliasing in non sample-based synths as their character instead of distortion.
Most of the chip based synthesizers in foo_midi are 16 bit precision. The only difference in precision is that the Adlib or OPL2/OPL3 based synthesizers are run at the native clock rate of the chip, then resampled. The MT32 emulator outputs at a super sampled rate of its own native rate.
Most of the chip based synthesizers in foo_midi are 16 bit precision. The only difference in precision is that the Adlib or OPL2/OPL3 based synthesizers are run at the native clock rate of the chip, then resampled. The MT32 emulator outputs at a super sampled rate of its own native rate.
Figured that because they're emulators at the end of the day trying to imitate the behavior and function of a real piece of hardware.
Then I don't even think the PC-Engine has a 16-bit synth. I still have a MiniDisc recording of R-TYPE (Part I) and attached a snipped here, after beating Stage4. Quantization steps are clearly audible.
It's not that it has a 16 bit synth. It's that I use a band-limited synthesizer to compose all of those chip emulators, which quickly simulates super sampling them at their native sample rate and downsampling to the output rate. It works by using pre-downsampled sinc pulses, which are mixed into an accumulator buffer for every synthesized delta, or change in amplitude in the chip waveforms. This accumulator buffer is then summed up into a running total, and a high pass filter is applied to the running total to simulate a leaky circuit and prevent DC offsets from happening too much.
This synthesizer, to remain reasonably fast, operates in 32 bit precision, and outputs 16 bit samples. The actual chips had way less sample precision than 16 bit, more like 8 bit, but they had high sample rates on their side, and high precision was not really necessary for such simple waveforms.
Thanks for your detailed description. When the first time I listened to such emulators in Winamp, my first impression was, even without taking analog distortion (by recording the real hardware) into account, some emulators sounded much better than the real thing.
I don't like to debate how an emulator should behave, as it is more or less affected by the preferences of developers and users. Take graphics emulation as example, how many 3D game console emulators allow customization of video resolution, texture filtering and other stuff? For example, if PCSX2 removed all improvements and only allows "native" emulation it will upset a lot of users for sure.
The same goes for sound emulation as well. While the OP didn't ask for 24-bit at the first place in previous posts, as long as the test sample is music with a lot of high frequency variations, I don't see any reasons why it can't be used in this listening test since it is just a test about audibility of high frequencies instead of synthesizer quality.
Thanks for your detailed description. When the first time I listened to such emulators in Winamp, my first impression was, even without taking analog distortion (by recording the real hardware) into account, some emulators sounded much better than the real thing.
I don't like to debate how an emulator should behave, as it is more or less affected by the preferences of developers and users. Take graphics emulation as example, how many 3D game console emulators allow customization of video resolution, texture filtering and other stuff? For example, if PCSX2 removed all improvements and only allows "native" emulation it will upset a lot of users for sure.
The same goes for sound emulation as well. While the OP didn't ask for 24-bit at the first place in previous posts, as long as the test sample is music with a lot of high frequency variations, I don't see any reasons why it can't be used in this listening test since it is just a test about audibility of high frequencies instead of synthesizer quality.
As long as no one uses emulators specifically to compare two different systems because that's where the trouble begins when people start doing that kind of crap without realizing that an emulator for one system may have some issues that the real piece of hardware does not and vise-versa. Uninformed people with lack of technical knowledge about how two pieces of hardware work and any possible revisions that could change something for better or worse often leads to some pretty stupid arguments online.
That's why I only suggested kode54's products since he is here to answer questions, and in Reply #3 the OP talked about ABX test of 44.1 with 96/192kHz, not ABX test of real game console vs emulator or emulator A vs emulator B. It would be strange if the thread continues in talking about how synthesizers works.
Also my mistake to mention Hi-res since what the OP wanted is not only the file format itself, but music with significant amount of high frequencies which can't be easily found in acoustic recordings.
To make myself clear, read Reply#23 carefully.
What's the differences of:
1. Download some 96/192khz flac files, resample to 44.1k and ABX
2. Render some chiptunes to flac in 96/192khz, resample the rendered flacs to 44.1khz, then ABX the flacs?
The generated flac files have nothing to do with any actual hardware or another emulator isn't it? The same goes for Emu de MIDI, if it is being used.
To make myself clear, read Reply#23 carefully.
What's the differences of:
1. Download some 96/192khz flac files, resample to 44.1k and ABX
2. Render some chiptunes to flac in 96/192khz, resample the rendered flacs to 44.1khz, then ABX the flacs?
The generated flac files have nothing to do with any actual hardware or another emulator isn't it? The same goes for Emu de MIDI, if it is being used.
What something does internally can have a big impact on the output. Attached files show why emulating at the correct rate internally is important but the output rate of the emulator is not
The thing with hardware is if recorded from the analog output then whatever sample rate used to record with is irrelevant but once you try to capture something digitally with no analog stages such as a digital audio output mod that completely bypasses the DAC on a system that uses odd sample rates internally then it becomes important for the receiving device to actually recognize and support the sample rate of the chip or problems arise, nothing stops you from resampling it to a more usable rate after receiving or recording it that doesn't cause any issues.
These files show why the output of an emulator is irrelevant. Because you can't tell the difference between 49,716 and 44,100 or 49,716 and 48,000, etc if properly resampled. However one rate if played with WASAPI or maybe a hardware MP3 player can result in it not playing at best and at worst it's anyone's guess what a specific device might start doing.
One file is at the internal rate of the emulated chip, the other is resampled afterwards to a more usable standard rate.
You still don't understand what I mean?
Read Reply#26 and get the file.
[1] The file "R-Type(HES).7z" is the source, inside of it is a 16-bit 96khz wav file.
[2] This *wav* file is resampled to 44.1k by SoX to another lossless format, like wavpack or flac.
[3] ABX file [1] and [2] by using the ABX plugin.
Totally unrelated to what you said isn't it? The ABX log will contain the checksum of file [1] and [2].
In case others would like to verify and reproduce the ABX test, file [1] and [2] will be used so that the checksum can be verified.
Understand now? It is a comparison of normal lossless audio file like flac and wavpack, tell me how can you make "R-Type(HES).7z" change the sound completely by using SoX?
These files show why the output of an emulator is irrelevant. Because you can't tell the difference between 49,716 and 44,100 or 49,716 and 48,000, etc if properly resampled. However one rate if played with WASAPI or maybe a hardware MP3 player can result in it not playing at best and at worst it's anyone's guess what a specific device might start doing.
One file is at the internal rate of the emulated chip, the other is resampled afterwards to a more usable standard rate.
Why an ABX test of 192/96k vs 44.1k can be changed to 49716 vs 44100 and 49716 vs 48000? You changed the test conditions already. You can also download some DXD files from 2L and resample it 123.456khz isn't it? Why it would be related to the audio file is synthesized or not?
[edit] Just took some time to find the Sonic MIDI file, and attached two audio files to show what I mean. Remember this topic is about using a high sample rate file with a lot of high frequencies to perform ABX tests.
The task: ABX the files attached.
Actually I used a MIDI from the FM set and not the General MIDI set. Difference in panning, instrumentation, and use of effects such as reverb and changing drumkits.
FM Set - Optimized for OPL3 sound cards of the day. Hard panning, use of certain instruments to work around limitations of OPL3 hardware.
GM Set - Made for General MIDI wavetable synthesizers of the day (probably optimized a bit for the Roland SC-55 add-ons of the day???). Soft panning, effects such as reverb, drum kit changes between songs.
You still don't understand what I mean?
Read Reply#26 and get the file.
[1] The file "R-Type(HES).7z" is the source, inside of it is a 16-bit 96khz wav file.
[2] This *wav* file is resampled to 44.1k by SoX to another lossless format, like wavpack or flac.
[3] ABX file [1] and [2] by using the ABX plugin.
Totally unrelated to what you said isn't it? The ABX log will contain the checksum of file [1] and [2].
In case others would like to verify and reproduce the ABX test, file [1] and [2] will be used so that the checksum can be verified.
Understand now? It is a comparison of normal lossless audio file like flac and wavpack, tell me how can you make "R-Type(HES).7z" change the sound completely by using SoX?
To answer how to change the audio with SoX. with those particular files. Use any sample rate below 32 KHz. If you really want to muffle it use something like 8 KHz.
The ABX result.
foo_abx 2.0.2 report
foobar2000 v1.3.15
2017-06-26 19:17:40
File A: [44k] Flying Battery Zone Act 2.flac
SHA1: 04dbee201c45e5914510b6da64b933dac5acf152
File B: [192k] Flying Battery Zone Act 2.flac
SHA1: bb1b5abc8d76cf17afa6c485d071a5a051b2438c
Output:
DS : Primary Sound Driver
Crossfading: NO
19:17:40 : Test started.
19:18:19 : 01/01
19:18:58 : 01/02
19:19:09 : 01/03
19:19:20 : 02/04
19:19:29 : 03/05
19:19:41 : 03/06
19:19:51 : 03/07
19:20:02 : 04/08
19:20:10 : 05/09
19:20:19 : 05/10
19:20:26 : 06/11
19:20:34 : 06/12
19:20:41 : 06/13
19:20:48 : 06/14
19:20:55 : 06/15
19:21:03 : 07/16
19:21:03 : Test finished.
----------
Total: 7/16
Probability that you were guessing: 77.3%
-- signature --
95f450798663bb439550dda8f55959a44d5a7bde
@Foobar3030 Since we have an ABX log, I will demonstrate how to interpret the log and examine the flac files.
[1] Copy all the text in the log and paste it in the verifier below:
http://www.foobar2000.org/abx/signaturecheck
[2] Verify the SHA1 values in the ABX log and see if they are the files I attached.
[1] and [2] are not security measures to avoid cheating. For example I mentioned that mzil found a pair of 2L files with time alignment problem, it is possible that 2L would fix the problem later and update their files. The checksums are used to identify if the files are changed or not.
[3] Refer to the post below to identify and avoid some common ABX pitfalls.
https://hydrogenaud.io/index.php/topic,110058.0.html
The points above have nothing to do with the audio files are synthesized or not.