Nero AAC Recommended Settings, Discussion Options

[Shandra]

Program used for compression: c:\WINDOWS\System32\cmd.exe

Additional command line options:
/c c:\Encoders\neroAacEnc.exe -q 0.5 -if %s -of %d && c:\Encoders\AtomicParsley.exe %d --writeBack --artist "%a" --album "%g" --tracknum "%n/%x" --title "%t" --genre "%m" --year "%y"

Thanks! (&Yikes - though about writing a simple c app. wich wraps to nero and then some tagger - wasn't aware that you can call cmd with more than one task)

About Lame and comparison - I also use Lame with ap_extreme, faac I used to call with -q 120 (though I had checked in that time lame extreme vs. faac q 100 with foobars abx tool and strange was that I couldn't differ mp3 from wav or faac from wav on various samples, but mp3 compared to aac was in the 85% range - apart from that it amused me I have given it no further thoughts so far) and later nero (6) LC normal (again with mentioned result in abx) so I think I will stay with .5 until I have the time to do some testing again for myself (or the better-then-mine ears here on the forum have come up with some new recommended settings sticky ).

[Ivan Dimkovic]

When I encode a file using -q .55 (latest Nenc), the files show up as CBR in Foobar. Is this normal? I thought they were VBR? (or is that a bug in foobar?)

Which foobar2000 version?! As far as I know it doesn't even display that...but yes, -q is definitely VBR.

... and similarly, when I encode using -cbr, looking at the bitrate indicator in Winamp (using the MP4 input plugin for Winamp plugin found at RareWares) the bitrate still fluctuates by a few kbps either direction of the target.

Same question: Is this normal? I thought they were "CBR"?

CBR in ISO AAC means 'VBR within the bit-reservoir limits' where bit reservoir size is known and defined by the standard.

In theory, it would be possible to make AAC perfect 'CBR' (where every frame is exactly the size of the desired bit-rate) but that would make no sense for this purpose.

[audioflex]

how would i turn on PNS?

this is a tool i would very much like to use like in the older nero versions, the lowpass is much too low on lc-aac, and pns fixes it.

[The Sheep of DEA...]

how would i turn on PNS?

this is a tool i would very much like to use like in the older nero versions, the lowpass is much too low on lc-aac, and pns fixes it.

Whether or not PNS completely "fixes" it is a matter for debate, but these options (as I've remarked in the larger command-line thread), appear to be hidden from the user and unavailable for modification, unfortunately. What do you think of my request for an "advanced options" category including the options to enable such things as PNS and lowpass frequency? It seems you are having a problem quite similar to mine

[Spaceboy]

Get AtomicParsley. Make sure to download v0.8.0, and not the latest one (buggy).

File extension: .m4a

Program used for compression: c:\WINDOWS\System32\cmd.exe

Additional command line options:
/c c:\Encoders\neroAacEnc.exe -q 0.5 -if %s -of %d && c:\Encoders\AtomicParsley.exe %d --writeBack --artist "%a" --album "%g" --tracknum "%n/%x" --title "%t" --genre "%m" --year "%y"

For some reason I can't seem to get this working with the above config. EAC finishes copying temp wav file to hard drive, then Nero Encoder window pops up and immediately closes.

This post has been edited by Spaceboy: May 9 2006, 21:30

[baloor]

Get AtomicParsley. Make sure to download v0.8.0, and not the latest one (buggy).

File extension: .m4a

Program used for compression: c:\WINDOWS\System32\cmd.exe

Additional command line options:
/c c:\Encoders\neroAacEnc.exe -q 0.5 -if %s -of %d && c:\Encoders\AtomicParsley.exe %d --writeBack --artist "%a" --album "%g" --tracknum "%n/%x" --title "%t" --genre "%m" --year "%y"

For some reason I can't seem to get this working with the above config. EAC finishes copying temp wav file to hard drive, then Nero Encoder window pops up and immediately closes.

Change the additional command line option /c at the begining there to /k
This will keep the command window open while you troubleshoot and will allow you to see what error is returned.

Be sure to have followed the advice and use AtomicParsley 0.8.0. Apart from the latest release being a bit buggy, the command --writeBack has been deprecated and will return an error using the above command line example.

This post has been edited by baloor: May 11 2006, 02:45

[Spaceboy]

Fixed

This post has been edited by Spaceboy: May 11 2006, 21:18

[=trott=]

There are some reports that 0.8.3 might have broken MP4 tagging, so using 0.9.x is recommended.

In fact it seems that 0.9 has broken mp4 tagging too. It writes the tags at the end of the file instead of at the beginning. The result is that importing the files into several music players is verrrry slow, it's not possible to stream the aac files using itunes and some programs can not read the tags.

After running mp4creator -optimize (which moves the tags to the beginning as far as I understand it) these problems disappear.

[Garf]

There are some reports that 0.8.3 might have broken MP4 tagging, so using 0.9.x is recommended.

In fact it seems that 0.9 has broken mp4 tagging too.

False.

It writes the tags at the end of the file instead of at the beginning.

That's legal.

The result is that importing the files into several music players is verrrry slow, it's not possible to stream the aac files using itunes and some programs can not read the tags.

After running mp4creator -optimize (which moves the tags to the beginning as far as I understand it) these problems disappear.

Why not ask the authors of those broken programs to fix their software instead of trying to hide the problem?

This post has been edited by Garf: May 16 2006, 09:00

[anaxamander]

In fact it seems that 0.9 has broken mp4 tagging too.

False.

Actually fubar2000 0.9x does improper tagging. And Nero seems seems to be implementing it as well. foobar2000 0.8.x does the better job of tagging - 'compliant' would be the word to use.

Why not ask the authors of those broken programs to fix their software instead of trying to hide the problem?

Okay, I'll bite.

Dear Nero Developer(s):

As author of your freeware encoder cli program, please fix your broken piece of software. Your manner of tagging files is incompatible with the ISO Base Media File Format.

[Ivan Dimkovic]

As author of your freeware encoder cli program, please fix your broken piece of software. Your manner of tagging files is incompatible with the ISO Base Media File Format.

Could you please pinpoint us to the part of the ISO 14496 that you believe we are breaking, especially with regards to the position of the MOOV atom in the physical file?

Thank you very much in advance.

[sony666]

Anyone who would not like to see "advenced options" please make yourself heard

[jarsonic]

My guess is that iTunes puts the tags at the beginning of the file to aid in / simplify streaming, the same way that ID3v2 tags are at the beginning of files to allow for easier streaming. Now, I'm not saying that Nero is obligated to change where their mp4 tags are in the file, because it doesn't seem to be against the standard. However, it would be nice to have an option to put the tag at the beginning of the file, if only to allow for streaming in iTunes. I only care a little bit, but my girlfriend complains that she can't listen to the songs in my iTunes library from her computer.

I know additional switches are being frowned upon (and I understand why, Garf), but truthfully it might be a useful one to consider. It doesn't affect the quality of the file, either way; it's more akin to the switch embedding album art. Am I wrong?

This post has been edited by jarsonic: May 16 2006, 14:32

[Ivan Dimkovic]

My guess is that iTunes puts the tags at the beginning of the file to aid in / simplify streaming, the same way that ID3v2 tags are at the beginning of files to allow for easier streaming.

MP4 file should not be streamable, there are MPEG-4 streaming protocols that deal with streaming of the MPEG-4 content.

Comparing ID3v2 and MPEG-4 atom-based-tags is useless - these are two completely different things.

One advantage of the tags at the beginning of the file is easy access from the software that does not need to know about mpeg-4 file format too much.

But in order to store tags at the beginning you:

- Either have to rearrange the file when the encoding is done (and that means you need double the space of the file on the disk, and also it takes time in case of large files) ; note that every modification of the file in the future that alters tags would mean that the file must be optimized again

- Or, leave some space at the beginning, for tags - this is OK, but it means sacrificing some storage space a priori

I know additional switches are being frowned upon (and I understand why, Garf), but truthfully it might be a useful one to consider. It doesn't affect the quality of the file, either way; it's more akin to the switch embedding album art. Am I wrong? smile.gif

We will think of this problem and try to find a solution acceptable for all.

[anaxamander]

As author of your freeware encoder cli program, please fix your broken piece of software. Your manner of tagging files is incompatible with the ISO Base Media File Format.

Could you please pinpoint us to the part of the ISO 14496 that you believe we are breaking, especially with regards to the position of the MOOV atom in the physical file?

Thank you very much in advance.

It isn't the position of the moov atom. Currently, its the last 80 bytes or so - until you implement tagging when it will balloon in size. Those last 80 bytes where you try to implement fubar2000's tagging scheme is the problem.

Specifically:
• Your 'meta' atom moov.udta.meta.tags.meta is in direct violation of the file format. From the documentation:

CODE

8.44.1 The Meta box
8.44.1.1 Definition
Box Type: ‘meta’
Container: File, Movie Box (‘moov’), or Track Box (‘trak’)
Mandatory: No
Quantity: Zero or one
A meta box contains descriptive or annotative metadata.  The 'meta' box is required to contain a ‘hdlr’ box
indicating the structure or format of the ‘meta’ box contents.  That metadata is located either within a box
within this box (e.g. an XML box), or is located by the item identified by a primary item box
[snip]
aligned(8) class MetaBox (handler_type)
extends FullBox(‘meta’, version = 0, 0) {
HandlerBox(handler_type) theHandler;
[snip]
}

So your meta box is non-compliant with four (4) parts of the 'meta' atom specification:
1-improper placement (your meta is in not in the enumerated containers).
2- you are missing the required 'hdlr' box.
3- versioning of your meta atom is wrong (though 3 is less a violation since its a renegade atom).
4-lemme count the 'meta' atoms. I should have ZERO or ONE. I have 'moov.udta.meta' (Oh, that's my limit of 1... oh, just for fun I'll keep on looking...) 'moov.udta.meta.tags.meta' (oh dear, that's 2).

• Your atoms/boxes after your improper meta are NOT atoms/boxes as defined in the ISO Base Media File Format. As an example, take your tool atom (moov.udta.meta.tags.meta.tool - hopefully you see a double-meta there). The specification defines an atom as (edited for clarity):

class Box {
unsigned int(32) size; //number of bytes in this box, including all its fields and contained boxes
unsigned int(32) type = boxtype; //four printable characters
}

The atom directly after 'meta' is 'tool'. But... if you have a 32-bit number for size... what is 0x00000474 ? 1140 bytes. But you don't have 1140 bytes after that to EOF - that 0x74 is coming from the 't' in 'tool' because you WROTE A 24-BIT NUMBER. The 'tool' atom you intended to write became the 'ool ' atom (with a NULL at the end). Just count by 4's after meta.

That's 5 times you've broken compliance. In 80 bytes no less!

The entire file format is based off that 4byte-4byte specification. It isn't reassuring that Nero's freeware encoder is in violation of the ISO Base File Format specification. And if you follow down the fubar2000's path like a lemming - there are things in 'tags' which I assume are trying to be atoms. So, how does one pack 'artist' into 4bytes. Bitpacking? And what about the duplication - artwork being embedded twice? Is Nero going to be fubar2000's lemming? Nero has the duplicate tool/encoder tags, will Nero be duplicating everything? I say, will Nero be duplicating everything?
--------
Additionally, you want to spread this tagging manner to the 3GP world. There is nothing in THAT specification that says anything about iTunes-style metadata being in their file format (search for the word 'asset' to find their way of storing metadata). So while it isn't forbidden, no 3GP device will show any metadata because it isn't properly stored. And, you won't find support for that in libmp4v2, so please consider not trying to tag 3GP (and later or derivative) files.

MP4 file should not be streamable, there are MPEG-4 streaming protocols that deal with streaming of the MPEG-4 content.

Uh, they CAN be streamable. How do you think iTunes streams mp4 over an airport connection? But when the receiving device has no 'moov' atom at the beginning to tell it what its bitrate... or anything is, the device can't decode it. I also think that when you tag with libmp4v2 in its default manner, you will prevent the iPod Shuffle from playing your files. It has been discussed in in this forum.

This post has been edited by anaxamander: May 16 2006, 14:55

[menno]

moov.udta.meta.tags.meta

You seem to have parsed the file incorrectly. You combine 2 things here

1: moov.udta.meta (iTunes compatible tag)

2: moov.udta.tags.meta (tagging that foobar2000 also uses)

The "tags" box is directly under the "udta" box. "tags" is not specified in 14496 so any parser will just skip it, along with the "meta" box inside.

What parsers will do with the iTunes tag is not completely clear to me, now that "atom" also seems to be defined in 14496. But a parser should know that "meta" should not be found under "udta" and would have to skip it.

BTW, I cannot find that specification for the "meta" box anywhere. Do you have an exact MPEG document number where you found this?

This post has been edited by menno: May 16 2006, 15:40

[menno]

EDIT: hmm was looking at wrong part
But anyway, you don't know how the "tags" atom is specified, so you can't say that there is incorrect data in there.

This post has been edited by menno: May 16 2006, 15:59

[anaxamander]

You are right in that it's not moov.udta.meta.tags.meta, its moov.udta.tags.meta. I typed incorrectly.

EDIT: hmm was looking at wrong part
But anyway, you don't know how the "tags" atom is specified, so you can't say that there is incorrect data in there.

I can say that if I were to literally follow the file structure and find every atom in the file, I would find 2 'meta' atoms. I don't care so much because I've accommodated the non-compliant data. But more bad news for you - it's that 14496 coming back at you. If you want to go creating your own atoms, then there is another part of the specification (and mpeg4ra.org) which deals with that too:

CODE

6.2 Metadata Structure (Objects)
6.2.1 Box
Type fields not defined here are reserved. Private extensions shall be achieved through the ‘uuid’ type.

I can't find 'tags' in 14996 or at mpeg4ra - its be a private extension. That should be a uuid atom then Sony PSP for example uses uuid atoms for their private extensions. Nero/fubar2000 does not. So that's more violations (you are using a 'reserved' name; you 'tags' atom isn't a uuid type).

As your colleague stated:
Why not ask the authors of those broken programs to fix their software instead of trying to hide the problem?

[menno]

You are right in that it's not moov.udta.meta.tags.meta, its moov.udta.tags.meta. I typed incorrectly.

EDIT: hmm was looking at wrong part
But anyway, you don't know how the "tags" atom is specified, so you can't say that there is incorrect data in there.

I can say that if I were to literally follow the file structure and find every atom in the file, I would find 2 'meta' atoms.

No, only one. You would only find two if you would assume that every atom always contains more atoms (because you don't know the "tags" atom) and that is of course not true.

This post has been edited by menno: May 16 2006, 17:54

[Csound]

Anyone who would not like to see "advenced options" please make yourself heard

I don't think it's necessary... The encoder works well enough for me at every bitrate I've tested.

As for recommended settings, I actually use the -q1 quality mode a lot. Why? In this mode I think it comes close to lossless quality at less than half the bitrate of a lossless files. The music sounds very well balanced, it doesn't suffer from the thin bass like Itunes AAC have, and it also sounds pretty involving for a lossy encoding. The bitrates seems to lie around 380 kbps in this mode but I have no problems playing the files on my portable devices, even my mobile phone plays them without exceptions. Great!

The only thing I'm curious about is if the bitrate really "max out" when using -q1 VBR mode? I know the encoder can go as high as 465 kbps but is this range really used in -q1 mode? If I listen critically the music looses some "scale" and "air" compared to to the original so if the encoder has higher potential than is being used today I would like to see an even better -q1 mode in the future (without having to use CBR 465 kbps...) I know many will see this as overkill but to me it's an alternative to lossless compression that is much less portable in comparison...

Thanks for a great encoder NERO!

[menno]

If you want to go creating your own atoms, then there is another part of the specification (and mpeg4ra.org) which deals with that too:

CODE

6.2 Metadata Structure (Objects)
6.2.1 Box
Type fields not defined here are reserved. Private extensions shall be achieved through the ‘uuid’ type.

I can't find 'tags' in 14996 or at mpeg4ra - its be a private extension. That should be a uuid atom then Sony PSP for example uses uuid atoms for their private extensions. Nero/fubar2000 does not. So that's more violations (you are using a 'reserved' name; you 'tags' atom isn't a uuid type).

As your colleague stated:
Why not ask the authors of those broken programs to fix their software instead of trying to hide the problem?

On another forum for your (assuming that you are the author of AtomicParsley) software, I found the following message:

http://sourceforge.net/forum/message.php?msg_id=3641462

I'm wondering why:

1: you feel the need to assume that "tags" has child atoms (mistake in your tool?)

2: "chpl" does play by the rules according to you (or are you just talking about the child atoms again)

3: "meta" in "udta" is correct for iTunes metadata? (ok didn't get that from that message, but still wondering )


I do not disagree that technically an uuid should be used, but I can't imagine it giving any problems anywhere in the future. No parser will skip a file because it has an unknown atom type.

[stephanV]

In this mode I think it comes close to lossless quality at less than half the bitrate of a lossless files. The music sounds very well balanced, it doesn't suffer from the thin bass like Itunes AAC have, and it also sounds pretty involving for a lossy encoding.

If I listen critically the music looses some "scale" and "air" compared to to the original so if the encoder has higher potential than is being used today I would like to see an even better -q1 mode in the future (without having to use CBR 465 kbps...)

Eh? Have you read the TOS and especially #8?

I normally wouldn't ask for this if settings were different, but for a setting like -q 1, I think this is rather important.

[Csound]

Eh? Have you read the TOS and especially #8?

I have now... Sorry for this mistake. I'm new to the forum and rushed in without reading TOS.

I normally wouldn't ask for this if settings were different, but for a setting like -q 1, I think this is rather important.

It's important to me too. I've done a lot of testing, blind A/B switching and more over the years with many different encoders. In the case of Nero AAC I have compared -q1 with -br 465 and -CBR465 to original PCM in depht and there are noticable differences between them on every level if you use analytical equipment. I am curious how the -q1 mode works in detail since I would like to validate my "subjective" experiences with some hard facts. The file sizes differ but that's not really evidence enough...

This post has been edited by Csound: May 17 2006, 09:44

[Ivan Dimkovic]

Your "analytical equipment" is probably difference signal analysis?

Of course, these files differ because AAC is a lossy codec, and quantization will differ for these two files.

But, what is important is that - at this bit rate, you can be pretty sure that -br 465 and -q 1.0 will (we are talking about stereo files, right?) have "noise" well below the human masking threshold.

So, both files should be pretty transparent to your ears

[Csound]

So, both files should be pretty transparent to your ears

Yes, they are pretty transparent to my ears. That's the reason I joined this forum, to follow the progression of a already pretty good lossy AAC encoder.

I'll try to make my subjective listening experiences presentable in a more objective way in the future.

This post has been edited by Csound: May 17 2006, 12:51