On 23/01/09 22:16, Jan Stary wrote: > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > > > Although I need to finalize the Perl script I was using to do this (life > > gets > > busy), in practice I was able to distinguish between samples created by > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > Carbon > > with HiFiMan Sundara headphones plugged in. To describe the circumstances + > > outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an > > array containing the givens A and B to get an unknown X; comparing 15 > > seconds of > > audio; audio/sox as the playback software. In the future, I would do >=16 > > trials, and perhaps conduct the tests from my desktop instead since it has a > > discrete amp and DAC. > > > > In offline resampling from 48kHz to 44.1kHz, the highs were most affected > > and > > that's what I was able to use to distinguish between samples. The > > percussion, > > especially the cymbals, sounded different in particular because the clip > > resampled by aucat had cymbal crashes that seemed to 'shimmer' much less > > (the > > decay was more rapid). The spectrograms seemed to confirm that the highs > > were > > most affected. > > > > Whether that means "low quality resampling" or merely that the results of > > the > > two commands can be differentiated is something I'm uncertain of. Either > > way, I > > don't know enough about C or sndio internals to be useful in that domain > > yet. As > > an aside, I did find this to be a useful resource for learning about digital > > audio resampling, and they recommend audio/sox there. > > > > https://ccrma.stanford.edu/~jos/resample/ > > > > I hadn't said anything about this earlier because I wanted to take the time > > to > > finish + document the script, reproduce my results with a royalty free > > sample at > > a greater trial count, and then post. Given that I haven't done so yet, I > > can at > > least post the commands used to resample the audio for those that are > > interested. > > > > > > # This was originally an opus file downloaded with www/yt-dlp. > > # Converting to WAV so both SoX and aucat can work with it. > > $ opusdec input.{opus,wav} > > Can you please point to the specific opus file, > so that I can reproduce exactly what you have done?
Sure. It was the first fifteen seconds in particular I compared against. The song is a guilty pleasure from my adolescent years that I felt like indulging that day, though, so please don't judge too much. :p Anyway, I used '--simulate' here, but of course you'd remove it to actually download the file. Note the format number if it feels important to check what exactly is being downloaded. $ yt-dlp -xf bestaudio/best --simulate 'https://www.youtube.com/watch?v=ei8hPkyJ0bU' [youtube] ei8hPkyJ0bU: Downloading webpage [youtube] ei8hPkyJ0bU: Downloading android player API JSON [SponsorBlock] Fetching SponsorBlock segments [SponsorBlock] Found 1 segments in the SponsorBlock database [info] ei8hPkyJ0bU: Downloading 1 format(s): 251 In case you're interested in my ~/.config/yt-dlp/config contents as well: $ cat ~/.config/yt-dlp/config --audio-quality 0 --embed-metadata --embed-subs --embed-thumbnail --format 'bestvideo*[height<=?1080][width<=?1920]+bestaudio/best' --output "${HOME}/Downloads/%(uploader)s/%(title)s.%(ext)s" --sponsorblock-mark default --sub-langs en,en-orig,-live_chat --write-description --write-info-json > > # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1). > > # > > # If I recall correctly, I converted to FLAC here because the WAV headers > > # generated by aucat and SoX differed, and so SoX would refuse to play WAV > > files > > # created by aucat. > > That would be a bug in itself. > How exactly does SoX refuse to play the WAVs created by aucat? Unsure what the error itself means, but I'll share it. Also, I forgot to add `-n` to aucat(1) in my previous mail, which is necessary to resample the file without playback. Oops. $ aucat -n -i input.wav -h wav -r 44100 -e s16 -o output.wav $ play output.wav play FAIL formats: can't open input file `output.wav': WAVE header error: cbSize inconsistent with fmt size > > $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac > > $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o > > output-aucat.flac > > sox dithers by default; can you try with sox -D > to see of the results are more similar? I'll add testing against a sample with `sox -D` to my TODOs. Life's been getting pretty busy, sadly. :( But I'd be happy to test when I get the time. Would be good to drop `-G` from the sox invocation now that I think about it. I do usually use it when resampling things offline, but it's an unneeded additional variable that could make isolating things in testing more difficult. > > # Generate spectrograms for later inspection/comparison. > > $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png > > $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png > > > > I'd certainly be interested in the ability to play audio in a way > > that avoids resampling altogether, > > If you have a 48kHz file, and your audio device can only do 44100, > then you have to resample, no way around it. This device can do 48kHz. I see what you're saying, though. In this case, I downsampled with both as a way to AB/X test the resampling implementations, to see if I could actually notice an audible difference or not. > > similar to what a user can do on FreeBSD with the > > following sysctl tweaks: > > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1 > > > > https://www.freebsd.org/cgi/man.cgi?query=sound&manpath=FreeBSD+13.1-RELEASE&format=html > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do > if the sample rate (or some other characteristics) is not what the device > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10 Unsure what it would do exactly. I think in FreeBSD's case specifically that it may just refuse to play audio and throw an error. That's what I remember it doing, but I'd have to go back and check to know for sure. This is why I assume they don't ship that as the default option. Certainly doing something like this isn't an expectation of mine. It's a "nice to have" that I've remained silent about for a while, and that's why I was intrigued to see someone else bring it up on misc@.
