Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Expert users discussion (Read 22991 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Expert users discussion

Reply #25 –
Quote from: audioflex on
yes, because subband encoders handle tonality and transcode much better for the most part.. (again, my opinion and i do not have to prove it), musepack is an encoder i trust.

why did i recieve warn?

And that's exactly where you are wrong. On this board, you have to prove it. I suggest you go read the TOS again. You probably didn't pay enough attention when you read it the first time on joining. I'm sure you did read it, you just forgot about it, mmk...  And pay close attention to #8, that's what you got warned for breaking.

Edit: Meh, Danimal was faster.

Expert users discussion

Reply #26 –
i was simply trying to state a point, musepack exposed all command lines and it did just fine, i can see why nero AAC developers would be afraid of "idiot experts" tarnishing their encoders reputation, but do not shut us all out like senseless children because of it.

Expert users discussion

Reply #27 –
Quote from: audioflex on
i was simply trying to state a point, musepack exposed all command lines and it did just fine, i can see why nero AAC developers would be afraid of "idiot experts" tarnishing their encoders reputation, but do not shut us all out like senseless children because of it.

Most people DON'T  know what they do when they use custom command lines. That's a simple but true fact. Better just trust the developers. They know best what they are doing.

Expert users discussion

Reply #28 –
MPC is mostly known among "expert users", AAC is encountered nowadays by almost everybody. The risk of "idiot users" is much bigger with AAC.

Expert users discussion

Reply #29 –
And MPC is so good that even idiot users have a hard time to mangle the quality.

Oh, and it's quality is certainly not due to the number of switches exposed. Rather the fine tuning.

Expert users discussion

Reply #30 –
agreed, but you can't say exposing switches hurt it any.

Expert users discussion

Reply #32 –
so they experiment and fail, that's how you tune an encoder better, by seeing what works, and what doesnt.

not by keeping one constant "failsafe"

Expert users discussion

Reply #33 –
Nero Digital Audio is tuned very heavily by number of subjective listening tests, lots of individual beta testers and advanced automated objective quality measurement tools.

For the version which was launched we spent months and months on perceptual tweaking and tuning (and the results were seen on 48 kbps AAC test I think  , and this process is continuous here, and currently are working towards low-bitrate LC (for compatibility) and 5.1 / 7.1 channel tuning  for squeezing even more quality.

Beta versions are internal for closed group of beta-testers, so no public beta-testing program is available at the moment. 

Our internal version of encoder has more than 100 parameters that can be tweaked - I don't think that is something for general public to use, I think it would only generate some l33t ultra long command lines and probably lower quality 

I think it is better this way - Nero Digital Audio is the brand for quality, and I really would like to be sure that anything that generates Nero Digital Audio file is certified and checked for the maximum possible quality.

Expert users discussion

Reply #34 –
Quote from: Gambit on
Quote from: audioflex on

agreed, but you can't say exposing switches hurt it any.

Yes, I can. Look at all the MPC users with the crazy commandlines they used at first and how they later realized how pointless it was after the warm fuzzy placebo effect weared out.


True. One of the reasons my collection is in MPC format is because it 'just works' without any fettling.

Expert users discussion

Reply #35 –
Quote from: Ivan Dimkovic on
Nero Digital Audio is tuned very heavily by number of subjective listening tests, lots of individual beta testers and advanced automated objective quality measurement tools.

For the version which was launched we spent months and months on perceptual tweaking and tuning (and the results were seen on 48 kbps AAC test I think  , and this process is continuous here, and currently are working towards low-bitrate LC (for compatibility) and 5.1 / 7.1 channel tuning  for squeezing even more quality.

Beta versions are internal for closed group of beta-testers, so no public beta-testing program is available at the moment. 

Our internal version of encoder has more than 100 parameters that can be tweaked - I don't think that is something for general public to use, I think it would only generate some l33t ultra long command lines and probably lower quality 

I think it is better this way - Nero Digital Audio is the brand for quality, and I really would like to be sure that anything that generates Nero Digital Audio file is certified and checked for the maximum possible quality.

internal version would be king if released, even to limited group of us more expert users here at HA, how do i apply for beta testing?

Expert users discussion

Reply #37 –
Quote
internal version would be king if released, even to limited group of us more expert users here at HA, how do i apply for beta testing?


Beta program is internal at the moment - but we will consider your wish if beta program becomes more open.

Also, even beta testers do not get internal encoder - this encoder is only for developers of the codec.

Expert users discussion

Reply #38 –
question, is the internal encoder the same? functionality wise but features are locked in public encoder?

or is this encoder stripped to coding level of all cmd lines that would be useful for a tester would be?

Expert users discussion

Reply #39 –
Quote
I think Nero is right in not exposing too many features.

Quote
Most people DON'T know what they do when they use custom command lines. That's a simple but true fact. Better just trust the developers.

I think so too.  It is indeed better for people who don't know what options to use or who could be confused by a huge list of advanced options.  That's why they shouldn't be "exposed" but still available for the advanced user to hunt down off of an advanced features list online. Read on to see what I mean...

Quote
May be maintaining of additional “beta” release with all switches unlocked could solve the problem?

Yes, or just not documenting the advanced switches for the average user, forcing serious users to find it themselves.  I'm willing to do some work to get at a lowpass or PNS option, even it means hunting for days
Quote
People will just get those betas/alphas, play with them, mess with them. They even have an additional feeling of bleeding edge, those "wow, I am using an alpha, I am really a Pro" fizzy feelings.

Yes, exactly... if these options are documented.  This is the whole point of my newer, fairer, more comprehensive argument, my friends.

Quote
Furthermore, I, as a user, do not want to be thinking about lowpass, PNS and whatever kind of switches there are. I do not even want to know what they are

Which is why these options shouldn't be exposed for you to see, but in a completely separate list online ("beta list?" )

Quote
I expect the encoder to make such decisions by itself.

Meaning that the encoder is to decide what audio I personally perceive of having better quality according to my personal preferences, my source material, my situation, my needs, etc, and then to know exactly what sources to specifically adjust lowpass on, or perhaps the encoder would suddenly provide [gasp] source-adaptive lowpass?!  Until such a thing can be implemented, the current one should be allowed to shift according to user preference, source material, situations, and any other factors which may be unique to each particular advanced user.  The "defaults" don't work on everything... Perhaps a universe of difference exists between audio and video encoding, but there are also some universal concepts worthy of consideration. Consider the new and power x264 video codec-- to solve horrid blocking problems in dark areas, I have to manually turn on --no-fast-pskip and adaptive quantization, but it looks fantastic now.  The same features/defaults are simply not applicable on all sources, and the encoder may be slowed down tremendously trying to figure out when, where, and how to use every option that could make things be just a bit better for a particular source or situation.  This is why the advanced user should be given the freedom to decide for himself.  The process of tweaking the seconder to a specific scenario isn't “overriding” the defaults, it's building upon them, supplementing them with the needed boost that certain users/needs/preferences/situations/sources/etc might require.

Which makes these arguments essentially invalid:
Quote
You are saying that you are smarter than the people that have developed the tool itself, programers, sound engeneers, etc, and that you know better than then on when to use what feature?

These statements are invalid because the defaults cannot be proven to be best for *everything,* (if they can, I'd like to see this proof) which is why the freedom should be there (after some hunting) for the advanced user to find an alternative that may fit his/her individual needs/prefs/tastes/situations/sources/etc/etc better than what may have been anticipated by the developer.  Let me be clear that in no way or form, overtly or by implication, do I intend to place the user's knowledge of the encoding process above the developer's, nor do I even make any statement that the developer's knowledge is not “best” in many situations.  However, the developer does not have to decide on exactly what options are best, given that these options and preferences and perceptions vary by source/audience/needs/etc.  LAME may have made the mistake of documenting these options in the encoder itself (much less differentiating between "this is fine" and "don't touch this" options), but a separate documentation for advanced options is far less likely to cause these sorts of problems.  Read above (in this post) under "I expect the encoder to..."

I came to this conclusion from my experience in video encoding, which despite its differences, operates in some similar ways in that different options can be more suitable for different sources, different people, different situations, etc.  This is the very reason why options exist: to expand the user's freedom to find something better for him/her and his/her situation and his/her source and his/her preferences and his/her compatibility and his/her time constraints and his/her needs, etc etc without allowing newbies or people who prefer simplicity be bogged down by seemingly useless or hurtful options--they won't be documented. 

Quote
The funny part is, vorbis has never exposed all these options even though it has certain models and modes that are used at different quality levels for different reasons, yet no one complains about that, because it's very well tuned.

Uhmm, what? This statement actually helps to make my point. Considering that Vorbis doesn't even *have* some of these AAC-specific options as part of the standard, --advanced-encode-option lowpass, noisetune, etc is used all the time.  The simple fact is, newbies just don't notice or care  This is exactly what I'm aiming for, advanced options which exist but are hard enough to find that the newbie can't abuse them

I saw this posted: "Ideally, users don't even need to think about "improving quality" the manual way, because the encoder should give the best quality it outputs all the time. Any modification could only lead to degradation of quality."
Ideally, yes.  In reality, it is nearly impossible to develop an encoder that is infinitely adaptable to an infinite number of variables.  XviD, x264, even Vorbis and musepack to a certain extent, when properly configured according to personal preference, situation, source type, and so on, can easily be better than the "default" options in each particular case.  Does that make the developers stupid, or mean they aren't doing their jobs right? Heck no--these guys are the bread and butter of the media compression scene.  They simply make their codec adaptable to all scenarios by providing the advanced user the options to do so.  In video compression, for instance, crispness, ME, adaptive quantization, subpel refinement, the number of references, etc is all configurable and *should* be configured by even the intermediate user.  I am the author of DeathTheSheep's x264 guide, so I understand the need to personalize the settings according to needs/situations/personal preferences/source material/free time/etc/etc.

Quote
Our internal version of encoder has more than 100 parameters that can be tweaked - I don't think that is something for general public to use, I think it would only generate some l33t ultra long command lines and probably lower quality.

True.  That's why these options (the more important ones at least), which still might increase quality if used correctly, should remain available for the advanced user to tweak and use--not listed or documented within the package, but in a separate list available --with some measure of effort-- online. 

Quote
Oh man, this thread is turning into a disaster. Why do you guys all care sooo deeply about having these switches or not having them?
Some people believe that one thing can infinitely adapt to all circumstances, all users, all situations, all preferences, all sources, etc perfectly, while the other group wants the freedom to have at their disposal at least some semblance of control over their own needs, which the first group considers counterproductive because it may lead to "abuse of these options."  The solution, of course, is: not even expose or document or include these option names in the package, but have them online elsewhere if they are actually needed.  Or provide an entirely separate build, which sort of defeats the purpose because newbies would still have at it thinking they know what they're doing.  "What they don't see, what they don't know even exists about the encoder, can't hurt them" is my philosophy too for general purposes, and what Nero hopes to accomplish.  But just in case, a list of advanced tweaks should be available online for the people who actually (goodness forbid) know exactly what they want. 
I love life--I really hope we can all reach a solution that will satisfy us all.  We simply have to be creative
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

Expert users discussion

Reply #41 –
Quote from: Gambit on
The Sheep of DEATH: To quote a man, far more wiser than I am:

"Yes, this is horrible, this idea."


Um, thank you very much for your support 

...
...



And yes, Erukian, FLAC is better than ALAC, freer, and it's even supported on my PocketPC, which is really sayin' something.
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

Expert users discussion

Reply #42 –
Quote
Meaning that the encoder is to decide what audio I personally perceive of having better quality according to my personal preferences, my source material, my situation, my needs, etc, and then to know exactly what sources to specifically adjust lowpass on, or perhaps the encoder would suddenly provide [gasp] source-adaptive lowpass?!

Uhm, you rely on the encoder to make such decisions much more than you can imagine. So, you might want to share with me, why do you find it be acceptible that the encoder makes a 100 decisions automatically and why there is 1 decision (e.g. lowpass) you think you know better how to handle. Quality is a lot less subjective as you make it seem here.

Quote
Consider the new and power x264 video codec-- to solve horrid blocking problems in dark areas, I have to manually turn on --no-fast-pskip and adaptive quantization, but it looks fantastic now.

Bad example, x264 doesn't have tuned defaults. Not at all.

Quote
I am the author of DeathTheSheep's x264 guide

I do not mean to insult you, but your guide is a good example of why people should not be allowed to touch switches. Some of your advice is really pulled out of the air (see the target bitrate section), at other times you come to the advice from really weird conclusions (see the the advice about trellis). And well, not advising fast first pass for a 2 pass and still advising analyse all, umh and subme 6 with brdo is quite weird if you are aiming for high speed and high quality. With your advice it would take me ages to encode a video and basically for nothing. 

Quote
But just in case, a list of advanced tweaks should be available online for the people who actually (goodness forbid) know exactly what they want.

I do not say people do not know what they want, just that the large majority of people wouldn't have a clue how to achieve what they want.
"We cannot win against obsession. They care, we don't. They win."

Expert users discussion

Reply #43 –
Quote from: audioflex on
total crap, PNS is an important tool that needs to be able to be specified if wanting to be used, stereo/mono modes as well, lowpass would be nice too.


I totally agree. While we're at it, the user should be able to override stereo/mono modes per spectral band. Say my source file is okay with M/S for the bass, but it needs more L/R for the treble. And then it also needs more cowbell. So I would also like to propose a --more-cowbell switch.

Expert users discussion

Reply #44 –
Quote from: Gambit on
The Sheep of DEATH: To quote a man, far more wiser than I am:

"Yes, this is horrible, this idea."

no, it is a great idea, if you don't want the switches, then don't use them. simple as that, ok?
and let us who do want them, have them to use.

please do not encourage the lobotimisation of the encoder for the stupid masses, thanks.

Expert users discussion

Reply #45 –
Quote from: audioflex on
Quote from: Gambit on

The Sheep of DEATH: To quote a man, far more wiser than I am:

"Yes, this is horrible, this idea."

no, it is a great idea, if you don't want the switches, then don't use them. simple as that, ok?
and let us who do want them, have them to use.

Yes, and I can see from your posts what you do with them...

Seriously, for that wannabe developer feeling, go play with something else.

Expert users discussion

Reply #46 –
Someone please help this poor thread, it's dying quickly

Expert users discussion

Reply #48 –
Quote from: Gambit on
Quote from: audioflex on

Quote from: Gambit on

The Sheep of DEATH: To quote a man, far more wiser than I am:

"Yes, this is horrible, this idea."

no, it is a great idea, if you don't want the switches, then don't use them. simple as that, ok?
and let us who do want them, have them to use.

Yes, and I can see from your posts what you do with them...

Seriously, for that wannabe developer feeling, go play with something else.

this is a personal attack?

i will not do anything to degrade quality, but it does not hurt to try out different options other than the standard "failsafe"

if you want a lobotomised encoder go use iTunes, Nero AAC needs to be handled more from the LAME mp3, of Musepack POV, more options, and also, like sheep said, the default does not work for everything.
keep that in mind please. 

Expert users discussion

Reply #49 –
@ audioflex:

Can you please stop repeating your wishes.
We all know now what you have to say and what you'd like to get.
But we all have seen that this absolutely doesn't meet the intentions of the Nero devs.

Do you really beleive you make them change their minds by repeating your arguments?

Please stop it.
lame3995o -Q1.7 --lowpass 17