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.

Poll

SV8 should provide just a limited set of switches. (Mainly the profiles)
[ 113 ] (64.2%)
SV8 should provide a full set of switches.
[ 63 ] (35.8%)

Total Members Voted: 193

Topic: What is your instance regarding Musepack SV8 switches? (Read 38841 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What is your instance regarding Musepack SV8 switches?

There's a heated discussion regarding SV8 switch options ocurring in this thread.

This poll is just intended to evaluate user's opinions, rather that deciding anything. (Obviously, since decision depends on format developers only)

Do you believe it's better to keep tons of tweakable switches, that might or might not lead to undesired usage; or instead offer just a limited set of switches that would strive to be "error proof" (I.E: The VBR presets and some functionality-oriented switches, instead of quality-oriented switches)?

What is your instance regarding Musepack SV8 switches?

Reply #1
profiles+
--silent (what does this do)
--start x
--skip x
--verbose
--scale x
--delinput
--forcewrite
--fadeshape x
--fadein x
--fadeout x

What is your instance regarding Musepack SV8 switches?

Reply #2
For me : error-proof switches

Actually I think the profiles of musepack are easy to use and explain exactly what they'll do.

-- standard
-- xtreme
-- insane
-- braindead

I think the choice is easy to make.

But to kick all the switchess out of there is a bit senseless for me.
Save the usefull-ones like delete source after encoding etc. .

What is your instance regarding Musepack SV8 switches?

Reply #3
I need at least --nmt and --tmn to customize quality & bitrate. These should definitely be kept.

What is your instance regarding Musepack SV8 switches?

Reply #4
Quote
Originally posted by Jan S.
profiles+
--silent (what does this do)
--start x 
--skip x 
--verbose 
--scale x 
--delinput 
--forcewrite 
--fadeshape x 
--fadein x 
--fadeout x


I agree with Jan.  Functionality based switches are perfectly fine.  Quality based switches should have their values determined via objective testing (abx), and then set statically.  If a problem is discovered, then it should be reported and these values updated.  This way, there is a much higher guarentee that everyone gets higher quality and that development continues to progress even moreso in this goal due to the cumulative nature of the tuning.  It keeps development focused, to the point, and on the right path, not distracted with wasteful and unnecessary endeavors such as providing *more* --braindead like switches.

 

What is your instance regarding Musepack SV8 switches?

Reply #5
Quote
Originally posted by CiTay
I need at least --nmt and --tmn to customize quality & bitrate. These should definitely be kept.


I think that if there has to be this functionality somehow, that it gets implemented more like the way vorbis works with the -q settings.  This would make more sense and would probably be more flexible.

What is your instance regarding Musepack SV8 switches?

Reply #6
I think that the "insane" preset should be renamed.  As it is, people that don't know much about MPC will still assume that it's a preset designed to give you better quality than extreme at the best possible bitrate.  The former is true, but the latter is not.  The word "insane" does not imply that it is "wasting" bits by encoding the full bandwidth.  OK, well, maybe it does in a way, since it's implying that you are insane, but hopefully this makes some sort of sense...

What is your instance regarding Musepack SV8 switches?

Reply #7
I voted for presets only, no tweaking.

I also think that 'insane' should be renamed. Maybe to 'transcoding'?

If ogg-style q setting is introduced, that would be good too.
Something like q = 0 -- telefone, ..., q = 3 -- standard, ... q = 5 -- braindead, q = max -- maximum tweaked tmn nmt etc.

'insane' or 'transcoding' should not have an equivalent q. Then the purpose of preset is clear.

Just my 2c.

What is your instance regarding Musepack SV8 switches?

Reply #8
Quote
Originally posted by Jan S.
profiles+
--silent (what does this do)
--start x 
--skip x 
--verbose 
--scale x 
--delinput 
--forcewrite 
--fadeshape x 
--fadein x 
--fadeout x


I second that.

What is your instance regarding Musepack SV8 switches?

Reply #9
I see no reason to keep insane.  The only reason I see to keep braindead is for people who use MPC and then transcode into other formats.  Other than that I think we should only have the main profile settings, and then maybe one high-quality high-bitrate setting.

What is your instance regarding Musepack SV8 switches?

Reply #10
Quote
Originally posted by TrNSZ
I see no reason to keep insane.  The only reason I see to keep braindead is for people who use MPC and then transcode into other formats.  Other than that I think we should only have the main profile settings, and then maybe one high-quality high-bitrate setting.

I second this. In fact I'm pretty sure that braindead is still overkill for transcoding.. maybe --insane and --braindead should be ditched in favor of a --transcoding switch. (btw, did anyone ever abx that --xtreme isn't enough for transcoding?)
A riddle is a short sword attached to the next 2000 years.

What is your instance regarding Musepack SV8 switches?

Reply #11
Hi,
Transcoding switch would be a good idea.

auldyin

What is your instance regarding Musepack SV8 switches?

Reply #12
Quote
Originally posted by auldyin
Hi,
Transcoding switch would be a good idea.

auldyin


We're going to need some abx tests to come up with this one.  It'll be interesting to see if we could find a setting that would produce mp3 files that are indistinguishable from directly encoded mp3's.

My rec is to start at braindead and work backwards.  Any other suggestions?

G

What is your instance regarding Musepack SV8 switches?

Reply #13
On topic:
Executive summary...
Switches are already there, keep them.  Better documentation is needed so people actually understand what they're doing.

High bitrate options (i.e. braindead type quality) are actually distinguishable on insanely expensive equipment, and less expensive equipment, with good ears which some people (though admitedly not the majority of people) *do* posess.  Since Musepack meets these people's needs at rates significantly better than lossless compression, full quality options are still a necessity despite the insistance by some that standard and xtreme are good enough for everyone.

Personally I don't use them, I see no need to since I can't really tell a difference between braindead and a tweaked braindead commandline. However, due to those that believe they can hear a difference, or want something in the neighborhood, but with a lower bitrate, I'm all for keeping the quality switches.  If they're in there now I see no reason to pull them unless nobody was using them.  What I'm surprised nobody's suggested is the inclusion of good documentation on the quality switches and suggested ranges.  Cool Edit's help files for transformation effects include a clear explanation of the parameters and the effective range of values for each.  Perhaps if people knew more about what they were doing with the switches they wouldn't mux things up.  Kind of like teaching a kid how to drive, you don't put them in the seat with a key and say, "Have fun," you show them what things do, how to operate the shifter etc. and provide some guidance before they ever turn on the car.

I do understand the primary goal of musepack, which is to provide transparency on most material at a minimal bitrate.  However, as good as standard is, I do know people who can tell the difference between standard, xtreme, and braindead in a blind situation with the samples in no apparent order and even spliced together in the same song with no idea where the changes occured (i.e. several seconds of one preset, then several of another and so on).

The difference between musepack and the original CD is minimal and the infrequent "artifacts" or differences are much prefered by everyone I know over mp3.  Higher bitrate options for those with better ears and better equipment do make sense to me.  My own personal use of braindead is more for peace of mind since I so kindly store my roommate's and friends' CD's in the event they want to hear something while at my place.  I prefer not to go back and re-encode their CD's and unfortunately lossless storage of everything isn't a realistic option for me like Frank suggested.

G

What is your instance regarding Musepack SV8 switches?

Reply #14
Well, of course swithces should be kept.

The reasons are:

1) Swithces could help to test encoder. For example, "I've found hard sample, it's transparent if --some_switch with value xxx is applyed" give more information, than just "I've found hard sample".
2) If someone want to experiment, why not?

To my ming the preset or full command string should be written in header (as it is now).

What is your instance regarding Musepack SV8 switches?

Reply #15
Quote
Originally posted by gdougherty

High bitrate options (i.e. braindead type quality) are actually distinguishable on insanely expensive equipment, and less expensive equipment, with good ears which some people (though admitedly not the majority of people) *do* posess


Any basis or proof for this statement?

--
GCP

What is your instance regarding Musepack SV8 switches?

Reply #16
Quote
Originally posted by gdougherty
However, as good as standard is, I do know people who can tell the difference between standard, xtreme, and braindead in a blind situation with the samples in no apparent order and even spliced together in the same song with no idea where the changes occured (i.e. several seconds of one preset, then several of another and so on).
Can you give any information who these people are and where can I reach them? Did they do statistically valid blind testing? What was the difference like, what did they hear?
Juha Laaksonheimo

What is your instance regarding Musepack SV8 switches?

Reply #17
Quote
Originally posted by vladimirovich
Well, of course swithces should be kept.

The reasons are:

1) Swithces could help to test encoder. For example, "I've found hard sample, it's transparent if --some_switch with value xxx is applyed" give more information, than just "I've found hard sample". 
2) If someone want to experiment, why not?

To my ming the preset or full command string should be written in header (as it is now).


Number 1 is probably the most valid argument for keeping the switches in I've seen yet.  How are we supposed to recommend improvements to the preset switches if we can't make changes and test them ourselves?

What is your instance regarding Musepack SV8 switches?

Reply #18
Quote
Originally posted by Garf


Any basis or proof for this statement?

-- 
GCP


Listening to the "blind test" CD I made and described in my previous post.  I tried it out with a friend who works at a hi-fi store.  I gave him no prior info except played the original wav first then played the splice tracks and asked him to describe what he heard.  We tested on about $30-40K worth of equipment and he correctly identified the varrying bitrate sections as either more or less transparent from the original wav track I played.  I used Blue Rondo A La Turk off The Dave Brubeck Quartet's Time Out CD for the test.  While it wasn't quite an ABX test, his correct identification of pretty much all the sections without any leading from me was enough to convince me that he was hearing differences.

What is your instance regarding Musepack SV8 switches?

Reply #19
Quote
Originally posted by JohnV
Can you give any information who these people are and where can I reach them? Did they do statistically valid blind testing? What was the difference like, what did they hear?


His name is Scott Weaverstadt and he works at the Denver, Colorado Listen Up location.

What is your instance regarding Musepack SV8 switches?

Reply #20
Quote
Originally posted by gdougherty
We tested on about -40K worth of equipment and he correctly identified the varrying bitrate sections as either more or less transparent from the original wav track I played.  I used Blue Rondo A La Turk off The Dave Brubeck Quartet's Time Out CD for the test.  While it wasn't quite an ABX test, his correct identification of pretty much all the sections without any leading from me was enough to convince me that he was hearing differences.
How many sections there were, and how many repetitions you made? Did you play the tracks in random order for each repetition?

What was the encoder version used?
Juha Laaksonheimo

What is your instance regarding Musepack SV8 switches?

Reply #21
Quote
Originally posted by gdougherty


Listening to the "blind test" CD I made and described in my previous post.  I tried it out with a friend who works at a hi-fi store.  I gave him no prior info except played the original wav first then played the splice tracks and asked him to describe what he heard.  We tested on about -40K worth of equipment and he correctly identified the varrying bitrate sections as either more or less transparent from the original wav track I played.  I used Blue Rondo A La Turk off The Dave Brubeck Quartet's Time Out CD for the test.  While it wasn't quite an ABX test, his correct identification of pretty much all the sections without any leading from me was enough to convince me that he was hearing differences.

gdougherty, you might be on to something here. However, in order to convince me, you need to describe your experimental method in more detail. And it needs to be repeatable. I'm a cynic by nature. Pretend you have discovered cold fusion (remenber that), and post all your test methodology. You might find that you did well, or you might get heeps of crap. Never mind.

As it is, your experiment will drift off the radar in about 2 days as yet another of those "someone said he did this test, but I'm not sure anyone was convinced".
Ruse
____________________________
Don't let the uncertainty turn you around,
Go out and make a joyful sound.

What is your instance regarding Musepack SV8 switches?

Reply #22
Just as an aside-

I've listened to very expensive Hi-Fi rigs in Hi-Fi listening rooms with pressed CDs and CDRs sourced from mpc files, and my conclusion was that one $30K setup sounded quite diffreent to another in tone and attack, etc, etc. What didn't stand out in these casual listening tests was any distinct difference between the mpc sourced discs and the pressed CDs.

In summary, these differences that Scott Weaverstadt heard:
* Could you hear them?
* What did he describe as the differences?
* Where they distinct differences or where they on the edge of perception?
Ruse
____________________________
Don't let the uncertainty turn you around,
Go out and make a joyful sound.

What is your instance regarding Musepack SV8 switches?

Reply #23
Sorry, back on topic:

* current quality switches
* all current nmt, tmn, ltq, etc switches
* Keep --braindead - this is a high quality oriented algorithm so why not have high bitrate settings for those who want them

The arguments in favour of slimming down the command line switches are a bit thin. Has the fact that Lame has even more user switches retarded its development? I don't think so. I think the management of development is more of an issue. MPC developemnt is under much tighter control than Lame for instance.

Switches are like options for users, just like options on any other product. What product marketer would reduce options with successive releases?

Currently any user can tweak mpc to give 400 kbps files, eg. That might be a reason for him to use mpc. Why limit this?
Ruse
____________________________
Don't let the uncertainty turn you around,
Go out and make a joyful sound.

What is your instance regarding Musepack SV8 switches?

Reply #24
Quote
Originally posted by Ruse
Has the fact that Lame has even more user switches retarded its development?


*YES*

If you look at the LAME project, especially before the --alt-presets were introduced, the fact that LAME had so many confusing switches (many of them contradictory), has "retarded" it's development.  Because of the huge amount of combinations of switches, the developers themselves didn't even know the correct settings for optimal quality!  It took the development of the --alt-presets to change this, and it's still quite a large problem because each of the different developers maintains seperate chunks of code indepedant of eachother, and activated via a switch.

LAME has 5 different ath types, 3 different psymodels (non-linear, nspsytune, gpsycho), 3 ath adjust methodologies, 8 different quantization selection methods, 3 different noise shaping types, 2 (used to be 3) different vbr modes, multiple joint stereo handling thresholds, etc, etc, etc ... need I go on?  Do you honestly think that true progress can be had if effort is put into working on each seperate version of these just so that more switches can be included (or maintained), instead of consolidating the effort to create a set of presets that work best in all situations?

Because of the mess LAME is in with all of these expermental switches and the way the code is just kind of hacked together and bits and pieces added here and there to make "more functionality" available, it's probably impossible to really get things back on track without either rewritting nearly the entire thing, or just scrapping it and starting over.

IMO there's a reason why LAME isn't progressing anymore and why there is so much left undone.. it's primarly because of this feature bloat and disjunctive "anything goes, let's add more experimental switches" ideaology.

I don't want to see this happen to MPC.