What is your instance regarding Musepack SV8 switches? Options

[lucpes]

And here's my new command line:

mppenc --quality 7.33 --maxbitrate 320 --minbitrate 128 --stereoquality 10 --bandwithquality 10 --temporalquality 10

So there's nothing new under the sun... I already know that I wouldn't be able to abx it against --quality 5 but it will sound better for transcoding... I just know it --kidding

perhaps it would be better to stick just to --quality?

[Uosdwis R. Dewoh]

Indeed - great job! Looking forward to putting it to use! Puts that other thread in a new perspective, too.

/ Uosdwis

[NickSD]

I think this poll should be closed... Since we have the q-scale now, everyone seems to be happy.

[Dibrom]

Originally posted by NickSD
I think this poll should be closed... Since we have the q-scale now, everyone seems to be happy.

Agreed. Poll closed.

[andy2kxp]

I say make 1 encoder for that has the quality scale and another encoder with the tweakable switches for people who enjoy tweaking or want to debug the current quality scale.

[Dibrom]

Originally posted by lucpes
And here's my new command line:

mppenc --quality 7.33  --maxbitrate 320 --minbitrate 128  --stereoquality  10  --bandwithquality 10 --temporalquality 10

So there's nothing new under the sun... I already know that I wouldn't be able to abx it against --quality 5 but it will sound better for transcoding... I just know it --kidding

Umm..

Why would you possibly want to limit the upper bitrate with MPC? One of MPC's greatest strengths is that it can go well over 320kbps for short periods if it needs to. It does this quite regularly on some of my music as well.

There should be no need to limit the upper bitrate unless you are planning to stream the files. Given your other switches, it really doesn't make sense either.

[b]
perhaps it would be better to stick just to --quality?

Probably.

[ssamadhi97]

Originally posted by lucpes
mppenc --quality 7.33  --maxbitrate 320 --minbitrate 128  --stereoquality  10  --bandwithquality 10 --temporalquality 10

heh, even more - if i understand the new switches correctly, the --stereoquality, --bandwidthquality and --temporalquality are all tradeoff switches - thus you'd push the encoder into one single direction with the above commandline (for example: sacrificing audio quality for stereo imaging quality)

[vladimirovich]

Well, I still thinks that q scale is bad idea. There are two reasons:

1) The units of quality scale are unknown.

2) It's limited above by 10, and I still don't understood why. In old encoder version all settings were in db, and the limitation by, for example, 100 db could be explained that -100 db is almost unheareble by any ear. But how could I garantee, that 10 is enough, if I don't know the units?

To my mind all psyhoacoustic tunings should be given in some basic units, like ms, or db, and they should be fully explained.

[Garf]

Originally posted by ssamadhi97

heh, even more - if i understand the new switches correctly, the --stereoquality, --bandwidthquality and --temporalquality are all tradeoff switches - thus you'd push the encoder into one single direction with the above commandline (for example: sacrificing audio quality for stereo imaging quality)

The problem of this naming of switches is that it gives the impression of giving more/higher 'quality' (though it is explained in the comments that they are tradeoffs).

What about

--stereovsquality
--bandwidthvsnoise
--temporalvstmn

Less chance of someone blindly changing them without stopping to think of the consequences.

To my mind all psyhoacoustic tunings should be given in some basic units, like ms, or db, and they should be fully explained.

You are assuming that it is at all possible to give the tuning parameters in simple to understand or explain units. That's won't be the case.

--
GCP

[Dibrom]

Originally posted by Garf


The problem of this naming of switches is that it gives the impression of giving more/higher 'quality' (though it is explained in the comments that they are tradeoffs).

What about

--stereovsquality
--bandwidthvsnoise
--temporalvstmn

Less chance of someone blindly changing them without stopping to think of the consequences.

I like this idea myself. Anything with the words "quality" on it will send people straight to tweaking whether they understand what they are doing and recognize the possible consequences or not.

[smg]

Originally posted by Dibrom


I like this idea myself.  Anything with the words "quality" on it will send people straight to tweaking whether they understand what they are doing and recognize the possible consequences or not.

I won't respond to that comment

[Dibrom]

Originally posted by smg


I won't respond to that comment

You just did.

[David Nordin]

Originally posted by Garf


The problem of this naming of switches is that it gives the impression of giving more/higher 'quality' (though it is explained in the comments that they are tradeoffs).

What about

--stereovsquality
--bandwidthvsnoise
--temporalvstmn

Less chance of someone blindly changing them without stopping to think of the consequences.



You are assuming that it is at all possible to give the tuning parameters in simple to understand or explain units. That's won't be the case.

-- 
GCP

I support this, makes sense and explains at the same time.

[Volcano]

Originally posted by andy2kxp
I say make 1 encoder for that has the quality scale and another encoder with the tweakable switches for people who enjoy tweaking or want to debug the current quality scale.

I second that. An encoder that has only the --quality scale (and maybe a few "utility" switches, like delete input file etc.) would be absolutely idiot-proof. You'd just have to promote it heavily to keep the clever-cloggs types away from the advanced encoder.

@ Frank: Do those --quality values have corresponding nominal bitrates, as in Vorbis?

CU

Dominic

[GeSomeone]

Originally posted by Volcano
I second that. An encoder that has [b]only the --quality scale (and maybe a few "utility" switches, like delete input file etc.) would be absolutely idiot-proof.

Maintaining two version would be contraproductive and cause confusion among the users. Almost everybody would want the "expert" version anyway
--
Ge Someone

edit: contra

[Volcano]

Maintaining two version would be contraproductive

Why? They'd be built from the same source (the only difference being the front end, which I guess is stored in one separate file anyway), and my idea is that the advanced encoder gets updated as usual, whereas the "easy" encoder is only updated if a beta or final version comes out. That shouldn't be too big a problem, shouldn't it?

Ach, forget it, someone will come up with a much better idea anyway

[R.A.F.]

Please, no, oh, no. No switches at all. I speak from experience. Because once I feeled like being a good codec-tweaker ...and some here still do. - But now I´m clean.
Edit:
Ohhh.... I just noticed that the last thread before mine was nearly before WWII. I was just wondering, why this "SV8"-thing became so actual again, as i thought it would be already dead & buried.

This post has been edited by R.A.F.: Sep 12 2003, 20:31

[rjamorim]

I wonder how did you find this thread to start with

[R.A.F.]

And imagine! I even didn´t vote for this poll out of WWII !! Okay, maybe it was simply because I was not yet born these days. No, seriously: I wanted to start a poll (which isn´t possible here for normalos like me; but I didn´t know) and so I discovered this one.....
BTW: You still can vote for my poll, it´s under "Off topic". There it´s allowed. Concerning upstream-speed of your internet-line. - Really interesting topic, I think.

This post has been edited by R.A.F.: Sep 12 2003, 22:36