The problem with testing high resolution audio (as you mentioned) is that it is almost never the same recording. When high resolution content is released, it is almost always remastered/remixed. Which means any attempt to compare it with the original CD release is going to be comparing the mixing/mastering work, which is likely to overwhelm any differences that result from the resolution.
A better test, which I don't see done very often is to start with a good quality high resolution source. Then downsample to 16/44. This way you have two recordings (the original and the downsampled version) that are of identical mixes, with the only difference being the resolution. Now you can perform an ABX test between the two and be reasonably confident that any differences are the result of the resolution differences and not other aspects of the recording.
Of course, if you perform this ABX test, you must make certain that the analog portion of your equipment (amplifier, speakers, etc.) is capable of reproducing the ultrasonic frequencies - otherwise none of the differences will be audible. And the levels must be matched - if one source is even slightly louder than the other, people will think it sounds better.
But even then, there's no guarantees because these two digital sources will be using different DACs - a hi-res DAC and a CD quality one. Even if both sources play to the same physical box, the DAC chip will probably employ different circuit paths for different resolutions. It may not be possible to completely tease out the audio differences that result from the different resolutions from those that result from using different DACs.
In other words, although we should be able to perform much better tests than people typically do, trying to perform a comparison where only the resolutions differ and everything else is equal is going to be an extremely difficult challenge.
I've been using (the very expensive) FileMaker Pro database for my personal databases for a long time. My needs are pretty simple, but FM has a few features that don't seem to be available (at least not in any simple or obvious way) with other database packages.
Specifically, these features are:
1: Text fields that don't have a length limit. Every text field in FM allows arbitrary amounts of text, including basic formatting. And it is stored efficiently - I'm not wasting a maximum-size field for every row in order to have this capability.
2: Numeric fields that include text. In FM, a number field is a text field that is sorted/parsed based on the leading string of digits. Non-numeric context following the digits is accepted and stored, but is not used for sorting or searching.
3: Multi-value fields. I can declare any field to accept multiple values. On the GUI form, I specify the maximum number of values to display, but internally there doesn't seem to be a limit. When searching, a value matching any of a field's values will match the field.
4: Embedded media. I can paste images into fields. I think most databases support this today, but it is trivially simple with FileMaker.
5: A trivially easy layout editor for designing input forms and reports.
The last time I looked at database packages (several years ago), no other product (not even Access) supported 1-3. Ironically, #1 was available in the 80's using Clipper (a compiler for dBase programs) using its "memo" type fields.
Authored Comments
The problem with testing high resolution audio (as you mentioned) is that it is almost never the same recording. When high resolution content is released, it is almost always remastered/remixed. Which means any attempt to compare it with the original CD release is going to be comparing the mixing/mastering work, which is likely to overwhelm any differences that result from the resolution.
A better test, which I don't see done very often is to start with a good quality high resolution source. Then downsample to 16/44. This way you have two recordings (the original and the downsampled version) that are of identical mixes, with the only difference being the resolution. Now you can perform an ABX test between the two and be reasonably confident that any differences are the result of the resolution differences and not other aspects of the recording.
Of course, if you perform this ABX test, you must make certain that the analog portion of your equipment (amplifier, speakers, etc.) is capable of reproducing the ultrasonic frequencies - otherwise none of the differences will be audible. And the levels must be matched - if one source is even slightly louder than the other, people will think it sounds better.
But even then, there's no guarantees because these two digital sources will be using different DACs - a hi-res DAC and a CD quality one. Even if both sources play to the same physical box, the DAC chip will probably employ different circuit paths for different resolutions. It may not be possible to completely tease out the audio differences that result from the different resolutions from those that result from using different DACs.
In other words, although we should be able to perform much better tests than people typically do, trying to perform a comparison where only the resolutions differ and everything else is equal is going to be an extremely difficult challenge.
I've been using (the very expensive) FileMaker Pro database for my personal databases for a long time. My needs are pretty simple, but FM has a few features that don't seem to be available (at least not in any simple or obvious way) with other database packages.
Specifically, these features are:
1: Text fields that don't have a length limit. Every text field in FM allows arbitrary amounts of text, including basic formatting. And it is stored efficiently - I'm not wasting a maximum-size field for every row in order to have this capability.
2: Numeric fields that include text. In FM, a number field is a text field that is sorted/parsed based on the leading string of digits. Non-numeric context following the digits is accepted and stored, but is not used for sorting or searching.
3: Multi-value fields. I can declare any field to accept multiple values. On the GUI form, I specify the maximum number of values to display, but internally there doesn't seem to be a limit. When searching, a value matching any of a field's values will match the field.
4: Embedded media. I can paste images into fields. I think most databases support this today, but it is trivially simple with FileMaker.
5: A trivially easy layout editor for designing input forms and reports.
The last time I looked at database packages (several years ago), no other product (not even Access) supported 1-3. Ironically, #1 was available in the 80's using Clipper (a compiler for dBase programs) using its "memo" type fields.