Using different compilers isn't sufficient to obtain encoders that produces different output files? IIRC, there were always OBJECTIVE difference between lame release (Mitiok vs Dibrom vs John33), though this difference was never audible. Am I wrong? I've no experience at all on software compiling...

Locale fix binary upload was built and carried out using "oggenc.c" which QuantumKnot corrected. A binary can be downloaded from test page.

Moreover, the difference of a binary is a difference of a compiler. I am using GCC. And an optimization option is also a standard range (default).

Furthermore, since it was a thing that it cannot compile well by VC, correction was added and re-uploaded to the source code. someone check whether this moves normally? (I do not have VC) The binary which builds this source code and is obtained brings the same encoding result as a front thing.

Isn't it enough to compare this new thing to original version and check which one is better?

Yes, a listening test in other words. You also need to check whether it doesnt change the average bitrate (and possibly use new setting to encode with), which is exactly what I already said in my first post.

I am Sorry, There was a serious mistake for locale fix version and source code. Now, it is substituted for the normal thing. If some people already downloaded, I will ask you to eliminate the older one.

Quote

why? could this hurt quality?

Bad influence will come out of hack of the stereo contained in QKTune depending on the case. It is clear at the low bit rate. If it is the transplant of only pre-echo and tuning, it should succeed in general (however, it cannot be guaranteed).

maikmerten> thanks a lot. This is confirming my suspicions. The "problem" with Garf/QK tuning, it's the gap existing between tonal music and percussive music. There's usually a small difference in bitrate between classical and other kind of music (~8...10 kbps, something like that on average). With QK tuning, the difference is much higher for the same quality setting. It's not a problem in real life, but for this test, it's a serious one. If we lower the setting in order to match 128 kbps, it will lower for sure the quality for tonal samples, like BachS1007 for exemple (because Garf/QK tuning have no quality effect with this kind of music). In other word, with AoTuV+QK we will probably gain quality on some (percussive) samples, but we will also lose (audibly?) quality on other. Really problematic.A solution would be to keep -q4, and accept the bitrate difference. But...

...I'm really far from sharing the opinion of people asking for bitrate exact match on the tested samples, but I know that the discussion always appears after the test. Here is the bitrate table of both encoders, on the 12 samples used for the AAC test

Other thing: my version of AoTuV+QK oggenc is broken. I've encoded samples with -q3,5 and -q3,7, and bitrate was terribly low (100 kbps on average). Quality is simply awful. -q4 is working perfectly, but at lower bitrate, there's a big problem.

Other thing: my version of AoTuV+QK oggenc is broken. I've encoded samples with -q3,5 and -q3,7, and bitrate was terribly low (100 kbps on average). Quality is simply awful. -q4 is working perfectly, but at lower bitrate, there's a big problem.