Hi,
i get a poor quality while encoding those samples: http://hydrogenaudio.org/forums/index.php?showtopic=58581

The encoder or the decoder could be broken. If not, please tell me why I have those weird results

Neither encoder nor decoder is broken.
From the help:
"-hev2 : Forces use of HEv2 AAC profile
Note that the above switches (-lc, -he, -hev2) should not be
used; optimal AAC profile is automatically determined from
quality/bitrate settings when no override is specified."

BTW -q 0.2 is producing only SBR, so forcing SBR+PS using -hev2 seems to be the bad idea.

I get the same poor result with -q 0.15 without forcing anything, i know that compression mode shouldn't be forced
but quality is really really bad. too bad

Can't reproduce with the original file you posted

Can you explain exactly how you encoded this? Did you use the command line directly or did you use some tool that uses the encoder?

I couldn't reproduce the phenomenon either. I encoded & decoded the original file with and without the PS setting using the standard and the SSE version of the Win32 Nero encoder and the Nero decoder (v. 1.1.34.2, dated August 6, 2007). All resulting files were of about expected quality without any major problems.

I suspected phase inversion in one of the channels, but "invert mix paste" in Audition and encoding with the specified settings didn't produce similar odd sound effects. Though, it attenuated the volume level close to the level of the OPs sample. (I phase inverted the right channel and mix pasted the file into the original).

Looks like some ~1000Hz high pass filter was applied together with some weird aliasing effects

I use the linux command line encoder directly.
The command was:
neroAacEnc -q 0.2 -if sunny.wav -of sunny-hev2.mp4 -hev2
no filters applied

Ah linux that makes a big difference. I will test it.

Seems this got automatically fixed by using GCC 4.1 instead of 3.4... so the next release/update will solve this problem (I think it's only with HE v2 and also doesn't see mto happen with all files).

Oh you use gcc? I was thinking you use Intel C++ Compiler.
So what about an amd64 version of the encoder

Don't count on that anytime soon. It requires a lot of testing normally, and that is hard to justify here for a linux version that we give away for free

It shouldn0t be too hard if there aren't much int/long pies, pointer arithmetics and cast hells.
Also, 3gpp releases the new source wich is 64 bit aware.

New question: when there will be released the fixed i386 version?

Best Regards,
Matteo

And how about compiling with the right compiler and optimization flags again, and reuploading without change? As it is – speed problems, and quality problems – it is a bit problematic.

Optimization falgs will give you 1% speedup improvements and less compatibility.
Just an AMD64 build will help, since it has double the registers if i386.
But if nero uses the coding technologies reference code from 3gpp.org then it's NOT amd64 aware so..

What I meant was that the Linux build is a lot slower than the Windows build, and it was suggested by the devs that it wasn't compiled in the optimal way (without MMX/SSE or whatever). Also Nero must be quite far from the reference code, mustn't it?

The GNU/Linux binary doesn't have any SSE instructions in it. (objdump -d linux/neroAacEng | grep xmm) (The SSE registers are called xmm0-7 (or 0-15 on AMD64). grep comes up empty, so no instructions touch the sse registers. or the %mm MMX registers, either.)

Building for AMD64 has lots of advantages: SSE and SSE2 are standard, so you don't need to have a fallback in case they're not present. The extra registers are a big help for floating point number crunching. The ABI is more efficient (function calls pass parameters in registers, instead of on the stack), so less cache traffic. Backwards compat with 386 (and even 8086) has led to some serious cruft and what are now poor design choices for modern CPUs (e.g. stack-based FPU). For stuff that can use SSE2, having it always available is very nice.

On my Core 2 Duo (E6600), wine neroAacEnc.exe is the fastest. The GNU/Linux binary is about half speed (not counting startup time if a bunch of wine stuff has to load from disk- I'm doing movie soundtrack encodes from an 8.6GB float32 wav file written by dcadec. The neroAacEng_SSE.exe binary runs two threads (on my dual core cpu), but maybe wine makes it really inefficient. When my system is otherwise mostly idle, the _SSE binary runs in maybe 10% less time than the regular windows binary, but uses twice as much CPU time. If anything is keeping one core busy, the _SSE binary under wine runs _much_ slower. Maybe as slow as 1cpu second per audio second. Still using all the cpu time it can get on both cores. So obviously I always use the non-SSE binary under wine. (I use wine 0.9.46 on AMD64 Ubuntu Gutsy)

Err, do the nero devs read these threads? There's no bug-reporting URL or information anywhere in the stuff that comes with the zip file, or that I can find on the nero site.

I guess the asm is written as inline asm using MSVC syntax or something? If there are a few key asm routines that would help a lot, you could speed up the GNU/Linux version by moving them to a separate .asm source file that you compile with nasm or yasm. That has the advantage of using Intel assembler syntax instead of AT&T, so you wouldn't have to rewrite things, just call them differently. (Sorry if you already know that. And wine works so well that if the windoze binary under wine is still even faster, I'd probably keep using it.)

Anyway, I logged on to the forum to report a couple bugs I've found in neroAacEnc Package build date: Aug 6 2007, version 1.1.34.2. I run the win32 binaries under wine 0.9.46 on AMD64 Ubuntu Gutsy.

1. 2pass mode from large input files doesn't use the requested bitrate. Instead it uses a very small bitrate that sounds horrible.

I have an 8.6GB (9230966852B) .wav file made with dcadec on a movie soundtrack which is 8013.06 seconds long.

The RIFF header has the file size modulo 2^32, i.e. ~611MB. 1pass encoding, e.g.
wine .../neroAacEnc.exe -br 398860 -if my.dcadec.wav -of my.dcadec.mp4
produces a nice sounding mp4 of the first 556.5s. And with -ignorelength, it produces a good AAC for the whole thing. So no real surprises so far.

With I get an AAC file with the right length in seconds, but the wrong length in bytes! It's only 91302706B (88MB), ~89.6kbit/s, and sounds horrible. Much much worse than a 2pass encode at 90kb/s of the first 9 min (done by omitting -ignorelength). The encoder's terminal output shows it running through all 8012 seconds on the first and second pass, though, and at normal speed. (about 29 minutes for both passes total on a 2.4GHz C2Duo using a single thread.) Sorry I forgot to copy&paste from my terminal window before I did stuff that scrolled the output off the screen. By the time I got this all typed, I probably could have run the encode again, but I didn't start it half an hour ago, and I'm almost done typing.

BTW, I'm using 2pass because I already encoded the video, so I know how much space is left for audio to hit just under 4482MB. If I'm feeling ambitious, maybe I'll get my encoding script to see how big the audio is after a VBR encode, and set the target video bitrate for the second pass based on that...

My input file is 6 channel 32bit float. It's RIFF "fmt " header uses WAVE_FORMAT_EXTENSIBLE. (see http://www-mmsp.ece.mcgill.ca/Documents/Au.../WAVE/WAVE.html in case my terminology doesn't match what you're used to.)

(I hope this is useful. I considered using xxd to hexdump in a format that xxd could turn back into a binary, but I thought the traditional hexdump format would be simplest. I don't expect the bug to be hard to reproduce.)

There are no more RIFF chunks later in the file, AFAICT. I searched for "RIFF", "WAVE", and "data", and neither of those strings appears in the file except at the beginning. So it's just a wav file with a wrapped length in the header.

I get the same results with wine neroAacEnc_SSE.exe (although the file is slightly smaller, 89831446B). I can't test with the GNU/Linux binary because of the next bug I found:

2. the GNU/Linux version doesn't support large files. strace output:
...

You can enable large file support by putting this before any system header files are included:

If there's a header file that all your source files include before anything else, the top of it is a good place to put feature-test macro definition like that.

I usually #define _GNU_SOURCE in my own projects, as that enables all the goodies, including LFS. If you don't want to get sucked into using GNU extensions (maybe you're still planning an OS X port...), then the _f_o_b define will just replace open with open64, etc., and everything will Just Work. (open() will be called with O_LARGEFILE.) Just make sure you use off_t instead of int any time you need to store a file offset or size, since it becomes a 64bit type.

Thanks very much for making a free high quality HE-AAC encoder available. I'm very impressed.

edit: I forgot to mention a feature request:
3. 2pass encoding from stdin would work if you save the stats to file, like video codecs (e.g. x264). If you don't want to expose the inner workings of your encoder to prying eyes that much more easily, then I understand (and lament that non-Free software always has to have mis-features like this). It would be really nice not to have 8.6GB temporary files... (OTOH I'll probably usually use -q, not -2pass -br).

Hope this helps, and happy hacking.

llama peter, thanks for the report. Yes, we are reading the forums here. Officially there is no number to call for support on our AAC encoder, but this forum is the right place

The optimizations from the windows build have been ported almost completely to the linux build, so the next linux version should be much faster.

The _SSE binary will disappear in the next version (has no advantage anymore over the normal build).

We did a lot of work on the bitrate control recently. 5.1 input with -2pass was not working correctly, this is also fixed in the next version. 5.1 support and quality will be greatly improved in that version.

You're right about the large file support (also for writing). Thanks for the information, we will try to solve this also for the next versions.

Saving -2pass stats to file is already supported internally, we're just not using it at the moment in the command line encoder. I'll consider adding that.

Hope I didn't forget to respond to anything

Cool. Thanks for the quick response. Sounds like good news on all fronts, then. BTW, I forgot to mention there is a man page for the GNU libc feature-test macros: man feature_test_macros. That's a good introduction to how to use them and what they do. The libc info page is another great doc. Sorry if you guys already have this figured out; I'm only assuming not because of the lack of large file support.

BTW, I figured out a command line to encode dts audio to aac via dcadec with no temp files:


AFAICT, mplayer -ao pcm:file=pipe.wav can only output s16le data. I probably couldn't hear the difference even if I tried, but I like the idea of feeding aacenc with a higher resolution decode of the source audio.

Thanks again,

Is there a fixed version of the encoder available? Or perhaps a workaround? I have this problem with 2pass encoding of long duration wavs on both AMD64 and Intel platforms.

I need some more info. You're trying to encode a very long (>4GB) wav file with 2pass? And are you using linux too?

Menno, I am not sure whether this is related to the issue Mr Hash mentioned, but I remember having difficulty encoding audio with a duration in excess of ~2 hours (for a single file) when passing the source through foobar2000 with the following parameters:


The same audio, when processed via a batch file with these parameters, encoded without any difficulty:


Could it be that something about the current implementation of -ignorelength is breaking the process, when the duration exceeds a certain length?

- M.

P.S.: 1.1.34.2, Intel processor, Vista.

I see, I will check that out

No this problem relates to wavs in excess of ~2 hours (16bit, 44.1khz) using both Windows XP Pro x64 (AMD) and Windows XP Pro x86 (Intel) OS.



Resultant m4a is always 40MB in size and has a bitrate around 30kbps.

Encoder version is 1.1.34.2.

Please advise. thanks

ps. same effect without -ignorelength.

Yes, reproducible here, thanks. It will get fixed.