[email protected] (Niels Möller) writes: > For a start, I implemented a *very* crude up-sampling, simply repeating > each core sample twice.
I've now tried the following experiment: Decode the core stream using unmodified libav, generating a 24-bit 48 kHz file. Then apply this crude repeat-upsampling to this file, and compute the sample-by-sample difference from the reference flac file. Then I get, at the end of the file, 899059: 864 5116 -468 -145 357 899060: -2346 -4270 -923 -611 -157 899061: 2163 4161 1178 686 919 899062: -759 -4693 -1505 -1406 -1042 899063: 1254 4742 1153 995 697 899064: -3511 -7763 123 -1121 -28 899065: 3055 8669 -1419 1079 287 899066: -5100 -8364 1267 -1516 43 899067: 6608 6793 430 1237 413 899068: -4935 -6059 -849 -1720 -703 899069: 2974 8292 86 1522 390 899070: -3851 -7902 512 -1258 -56 899071: 5415 6983 -111 685 49 The residuals are both alternating in sign, and larger than what I get when decoding the xll data, so I think this makes it clear that there should be some decent filter for the upsampling. The residuals should encode (mostly unaudible) audio contents in the frequency band from 24 kHz to 48 KHz (and audio close below 24 kHz which was filtered out for the core channels), and errors from the lossy encoding, but not artifacts of bad upsampling. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
