|
|
Post by kamedo2 on Jan 8, 2014 14:48:00 GMT
The bitrate of the samples. MPEG sequence (short), Huge set of 164 samples from the last public test, randomly picked from lvqcl, Gecko, Kamedo2, Kohlrabi's libraries, the new HA thread.  |
|
|
|
Post by kamedo2 on Jan 8, 2014 16:43:35 GMT
|
|
IgorC
Administrator
Posts: 41
|
Post by IgorC on Jan 10, 2014 14:09:31 GMT
Now samples are here it's time for packages. A few things. Normalization and resamping. Possible chain is: source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav Resampling: SoX VHQ Normalization: The past public listening tests and my private listening tests slightly differs in the way the normalizations are done. Public - unweighted RMS, using the ABC/HR for Java Private - replaygain weighted RMS, using my rawgene4 |
|
|
|
Post by win32vb on Jan 10, 2014 23:39:37 GMT
Now samples are here it's time for packages. A few things. Normalization and resamping. Possible chain is: source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav • source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav I object to this because it will cause the output files to be randomly louder and softer due to the random "peak" value found in each file during normalization. This random volume change could provide a clue for ABXing files that otherwise would sound identical. The fact that one codec outputted a file with a higher peak than another doesn't mean that the file will sound louder, just that the lossy phases added up to make a big peak. • source.wav -> lossy encoder -> decoded 32-bit.wav -> resampling -> attenuate by 3 dB -> 16-bit.wav This is what I recommend to do. The audio file will be encoded "as is" (at source level) and then attenuated to protect against clipping. This also more like real world use, where the audio file is simply transcoded "as is", and then stamped with a "ReplayGain" level that specifies the amplification (+/-) during playback. • source.wav -> attenuate by 6 dB -> lossy encoder -> decoded 32-bit.wav -> resampling -> 16-bit.wav I don't like this idea either, because it will give Opus (and possibly Vorbis) an unfair advantage. The lower input volume will cause codecs like MP3, WMA, and AAC to use lower bitrates (which will mess up your bitrate calibrations) and garble more frequencies, since they use the absolute amplitude to decide what to keep and what to throw away. This phenomenon is one of the reasons Opus excels at nature sounds. It doesn't garble soft background sounds (hiss/ambiance) while practically all other codecs do, even at significantly higher bitrates. If you need a Opus decoder that decodes to a 32-bit float WAV file, let me know. I believe that I can write one without much difficulty (I already wrote one for 16-bit, I would just need to use the float decoder API instead).  |
|
|
|
Post by Gainless on Jan 11, 2014 2:11:13 GMT
Kind of a bummer that we don't have a Dubstep sample in there, would have been definately an enrichment although I agree with the principle of random selection.
|
|
|
|
Post by kamedo2 on Jan 11, 2014 4:52:43 GMT
Now samples are here it's time for packages. A few things. Normalization and resamping. Possible chain is: source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav • source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav I object to this because it will cause the output files to be randomly louder and softer due to the random "peak" value found in each file during normalization. This random volume change could provide a clue for ABXing files that otherwise would sound identical. The fact that one codec outputted a file with a higher peak than another doesn't mean that the file will sound louder, just that the lossy phases added up to make a big peak. I mean, RMS normalization by the normalization, not normalizing the "peak". |
|
|
|
Post by Steve Forte Rio on Jan 11, 2014 10:24:33 GMT
• source.wav -> lossy encoder -> decoded 32-bit.wav -> resampling -> attenuate by 3 dB -> 16-bit.wav This is what I recommend to do. The audio file will be encoded "as is" (at source level) and then attenuated to protect against clipping. This also more like real world use, where the audio file is simply transcoded "as is", and then stamped with a "ReplayGain" level that specifies the amplification (+/-) during playback. I like this way. -3 dB should prevent deep clipping, anyway. But also it is possible to use first variant: • source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav Here I suggest to calculate total peak value for groups of decoded-resampled files (from each format) for each sample. It will be something like "prevent lipping according to peak/source: album", but there will be "sample" instead of "album". If it is possible, this is the best way to go, IMO of course. |
|
|
|
Post by Gainless on Jan 11, 2014 11:49:07 GMT
I like this way. -3 dB should prevent deep clipping, anyway. But also it is possible to use first variant: • source.wav -> lossy encoder -> decoded 32 bits .wav -> resampling -> normalization -> 16 bits .wav Here I suggest to calculate total peak value for groups of decoded-resampled files (from each format) for each sample. It will be something like "prevent lipping according to peak/source: album", but there will be "sample" instead of "album". If it is possible, this is the best way to go, IMO of course. I think it would be more sensible to resample the lossless source (48 khz, since Opus would have to resample otherwise) and not the lossy encode, so this one doesn't get altered. |
|
|
|
Post by Steve Forte Rio on Jan 11, 2014 14:30:30 GMT
I think it would be more sensible to resample the lossless source (48 khz, since Opus would have to resample otherwise) and not the lossy encode, so this one doesn't get altered. We test encoding of 16/44.1 audio and must not have targeting on any particular encoder. |
|
|
|
Post by kamedo2 on Jan 11, 2014 19:21:07 GMT
I re-sampled the MPEG samples to 44.1kHz and normalized the peak to 0dB. sox1441 input.wav -b 16 output.441.wav rate -v 44100 gain -n |
|
|
|
Post by Gainless on Jan 12, 2014 12:48:39 GMT
I think it would be more sensible to resample the lossless source (48 khz, since Opus would have to resample otherwise) and not the lossy encode, so this one doesn't get altered. We test encoding of 16/44.1 audio and must not have targeting on any particular encoder. I didn't know that the 44.1 khz is one specific criterion for the test, just thought it would be only fair not to make up unnecessary obstacles for the performance of one encoder, in this case Opus, since the other ones support 48 khz without resampling. |
|
|
|
Post by kamedo2 on Jan 12, 2014 15:29:53 GMT
The difference between unweighted RMS normalization used in ABC/HR for Java, and Replaygain's Yulewalk weighted RMS normalization. The test sample is "Waiting".  The difference is not very big. These two produces roughly the same results. |
|
IgorC
Administrator
Posts: 41
|
Post by IgorC on Jan 12, 2014 15:40:03 GMT
|
|
IgorC
Administrator
Posts: 41
|
Post by IgorC on Jan 12, 2014 15:58:46 GMT
The difference between unweighted RMS normalization used in ABC/HR for Java, and Replaygain's Yulewalk weighted RMS normalization. The test sample is "Waiting". The difference is not very big. These two produces roughly the same results. Thank You, Kamedo2. That means we have a suitable normalization in ABC/HR Java. |
|
IgorC
Administrator
Posts: 41
|
Post by IgorC on Jan 12, 2014 23:54:41 GMT
There was a suggestion to not use dither probably because the original source is actually CD material (16 bits).
I will prepare prototype N3 with all processing done in foobar2000 player (decoding and resampling at 32 floating point and only a final stage a bit depth reduction to 16 bits).
It means we should ship a big pre-decoded .wav files but this is a price for a better pre-processing.
P.S. Guests, please register.
|
|
