Hello. I was using NeroAacEnc as long as I was active Windows user. Not long time ago I began to use Ubuntu and my goal was to get the same experience. And few days ago I've tried Linux version of my favorite codec. When I compared encoded files, I noticed that they slightly defferent in the beginning and in the end of the file. In the figures below you can see the beginning of the file.
(http://img818.imageshack.us/img818/3703/3orig.png)
Fig.1 Source
(http://img31.imageshack.us/img31/9209/2lin.png)
Fig.2 Made by Linux version
(http://img713.imageshack.us/img713/9159/1winr.png)
Fig.3 Made by Windows version
(http://img11.imageshack.us/img11/7637/0lin.png)
Fig.4 Made by Windows version in Ubuntu through the Wine
To tell the truth - I can't hear any difference between those files. But it makes me crazy. Why they are different and why this difference appears only in the beginning and the end of the file? And which of the version is more accurate? I've tried to find the answer by myself but didn't succeed.
P.S. Excuse me for big pictures but I can't understand how spoiler tag is working here and I don't now how to hide them.
Funny how the title bars of these files show WAV and FLAC files, not AAC! And since you cannot ask for information from the person who [air quotes] sold you the files, I guess you might never know.
Oh, sorry, I totally forgot about it. This program (Sonic Visualizer) can't work directly with AAC. It only works with WAV, FLAC and some others maybe. Convert my AAC files to FLAC was the most suitable for me. All AAC files was converted to FLAC in Windows with MeGUI. I think it shouldn't interfere the comparison.
What differences do you see? Maybe I am missing something. Regards.
And which of the version is more accurate?
MSVC compiler is what we test with and work with during development
What differences do you see? Maybe I am missing something. Regards.
If compare figures 2 and 3, you can notice differences around 14KHz. And again, such differences only occur at the beginning and the end of the file. At this figures you can notice that right part of screenshots are identicall.
lvqcl,
Thank you for your answer. I have a dilemma at now. To use native Linux version or to use Windows version through the Wine. Maybe other options. I have to think about it.
If you can't hear the difference why do you care?
You know, it's some kind of paranoia. I will think that Linux version works slightly different from Windows one. And every moment I will encode my music, I will think that it can be encoded inproperly.
And the most annoying is that using Windows version through the Wine is not the decision. Because I think that the Wine can bring more errors at encoding process than anything else.
If you aren't being rational, how will accept what people say? Why would anyone waste their time helping you at this point?
To be honest I've already got the answer. It isn't what I wanted to hear, but who cares. Linux version wasn't tested by developers as it was with Windows one.
If you can't hear the difference why do you care?
I, for one, would be curious if two different builds of what was supposed to be the same application, would produce different output. Just because I couldn't hear the difference in a single sample, it doesn't mean it isn't due to a bug.
Lossy encoders are well known to frequently produce negligibly differing output between different builds, such as those produced by different compilers, all else being identical. Being compiled on/for a different operating system with different APIs and suchlike is just going to increase the probability. This should not be surprising!
In other words, I doubt that the differences here are in any way significant. _faber_, your ears seem to agree with that conclusion. That’s both sufficient and necessary as far as Hydrogenaudio is concerned!
And hey: on the off-chance that you’ve uncovered something that actually matters, you’ll have helped the developers: everyone wins.
What happens when it is discovered that the Linux version also conforms to specification?
_faber_ it has been proven that iTunes/QuickTime AAC encoder is better than Nero AAC encoder, why don't you use for example foobar2000 + qaac/qtaacenc if you care so much about the "I can't even ear the difference" different?
PS
I will post the many hearing test I saw around asap, I need to find them.
One: http://listening-tests.hydrogenaudio.org/i...-a/results.html (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html)
Evidence please!
http://www.hydrogenaudio.org/forums/index....st&p=795546 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=94970&view=findpost&p=795546) (personal listening test)
You know every bit as well as I do that your link fails to justify sweeping generalizations about the relative quality between the two codecs.
_faber_ it has been proven that iTunes/QuickTime AAC encoder is better than Nero AAC encoder, why don't you use for example foobar2000 + qaac/qtaacenc if you care so much about the "I can't even ear the difference" different?
PS
I will post the many hearing test I saw around asap, I need to find them.
One: http://listening-tests.hydrogenaudio.org/i...-a/results.html (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html)
Do I bin this post now or are you still working on the never-ending task of proving your claim for all listeners, all samples over all bitrates and modes?
_faber_ it has been proven that iTunes/QuickTime AAC encoder is better than Nero AAC encoder, why don't you use for example foobar2000 + qaac/qtaacenc if you care so much about the "I can't even ear the difference" different?
PS
I will post the many hearing test I saw around asap, I need to find them.
One: http://listening-tests.hydrogenaudio.org/i...-a/results.html (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html)
Do I bin this post now or are you still working on the never-ending task of proving your claim for all listeners, all samples over all bitrates and modes?
Of course I can't prove every single codec at every bitrate but listening test are the only proof to say a codec may be better than another, or not?
If you had worded it that way then it would have been OK, but you didn't.
If you had worded it that way then it would have been OK, but you didn't.
Apologize again to everyone, English is my third language. I've moved to USA ~6 years ago.
I apologize about not being specific about what type of evidence is needed in order to say that one codec is better than another without qualification.
It would be along the lines of known technical differences, such as those given to explain why Lame may be better than Blade, for instance.
Do I bin this post now or are you still working on the never-ending task of proving your claim for all listeners, all samples over all bitrates and modes?
That is very important point indeed.
Not being a smart hat but here is my point of view:
all bitrates:Here is no doubt. The results of public tests aren't interpolable to other bitrates. Though there is still some information (a hint) what to expect for similar bitrates (close to tested bitrate).
all listenersIt depends of amount of results/listeners and how big the difference was.
More than 10 results per sample + significant difference is enough to say that it's valid for average listener. So it's safe to say that Apple AAC encoder is better than Nero's at 96-100 kbps for
average listener and it's true for absolutely
all listeners who have submited complete results . We don't need every single human to participate in public tests.
Now, there was a statistical difference between Fhg and Apple AAC encoders but both were on par for
some individuals so it's not safe to say that Apple is better than FhG for all listeners but it is for an average one ... at 96 kbps.
all samplesIf the number of samples is high enough (it's case for HA public tests) then it's safe to say that codec A is better than codec B for
average material.
_faber_ it has been proven that iTunes/QuickTime AAC encoder is better than Nero AAC encoder, why don't you use for example foobar2000 + qaac/qtaacenc if you care so much about the "I can't even ear the difference" different?
PS
I will post the many hearing test I saw around asap, I need to find them.
One: http://listening-tests.hydrogenaudio.org/i...-a/results.html (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html)
I need something that works in Linux. Native one, without help of Wine.
_faber_ it has been proven that iTunes/QuickTime AAC encoder is better than Nero AAC encoder, why don't you use for example foobar2000 + qaac/qtaacenc if you care so much about the "I can't even ear the difference" different?
PS
I will post the many hearing test I saw around asap, I need to find them.
One: http://listening-tests.hydrogenaudio.org/i...-a/results.html (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html)
I need something that works in Linux. Native one, without help of Wine.
Oh... I don't think it's possible, qaac requires a library you can find inside QuickTime and/or iTunes and qtaacenc requires QuickTime to be installed.
If you can't test True VBR let me know if you'd like me to convert anything for you for a quick listening or spectrum test.
I need something that works in Linux. Native one, without help of Wine.
I used neroAacEnc under linux to convert my FLACs to AAC for a while. I listened to them on my iPod. I didn't run into any problems.
I used neroAacEnc under linux to convert my FLACs to AAC for a while. I listened to them on my iPod. I didn't run into any problems.
Glad to hear that. I've already put up with this differences. But if anybody can prove that such differences are not due to the bug, please tell it. It will totally appease me.
Did I miss some other conversation where someone confirmed that there is “the bug”, whatever that is? Or are you asking, with confusing wording, if there is a bug?
Did I miss some other conversation where someone confirmed that there is “the bug”, whatever that is? Or are you asking, with confusing wording, if there is a bug?
Yep, exactly. I just want to know if there is a bug. Sorry for my English.
As db1989 already pointed out it's perfectly normal to get slightly different outputs from binaries built using different compilers. It's also normal to get slightly different output from the same binary according to the system architecture in use.
Demonstration:
I have three GNU/Linux PCs to hand. One runs 32-bit Debian on AMD Athlon64 hardware, another runs 32-bit Ubuntu on Core Duo (old 32-bit hardware), and another runs 64-bit Debian on Core 2 Duo. Using the identical neroAacEnc Linux 1.5.4.0 binary on each I encoded the same wav with default settings. Each encoding produced a file with a different md5sum, and the AMD based machine produced a file whose bitrate is 1 kb/s different than the two Intel machines.
This is not a bug, it's predictable and normal behaviour.
NeroAacEnc uses loads of floating points maths and small roundoff differences can cause slightly different results. The difference between Intel and AMD machines is because it uses the Intel IPP library for some signal processing, and that uses differently optimized versions depending on the hardware it runs on.
It's also possible there is a bug in the encoder where it is at some point relying on undefined behavior.
Nobody (not even with the source) can "prove" there are *no* bugs in the encoder. That's unfeasible for any-nontrivial program, and only some theoretical mathematicians have ever attempted it.
Basically, the behavior you see is normal and excepted, and doesn't necessarily warrant further speculation.
Takla,
Garf,
I got it.
Thank you, everyone, for your answers.