HydrogenAudio

Hydrogenaudio Forum => Polls => Topic started by: rjamorim on 2002-06-02 20:37:48

Poll
Question:
Option 1: SV8 should provide just a limited set of switches. (Mainly the profiles) votes: 113
Option 2: SV8 should provide a full set of switches. votes: 63
Title: What is your instance regarding Musepack SV8 switches?
Post by: rjamorim on 2002-06-02 20:37:48
There's a heated discussion regarding SV8 switch options ocurring in this (http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=2037) 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)?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Jan S. on 2002-06-02 20:43:30
profiles+
--silent (what does this do)
--start x
--skip x
--verbose
--scale x
--delinput
--forcewrite
--fadeshape x
--fadein x
--fadeout x
Title: What is your instance regarding Musepack SV8 switches?
Post by: -=Ducky=- on 2002-06-02 21:19:31
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. .
Title: What is your instance regarding Musepack SV8 switches?
Post by: CiTay on 2002-06-02 21:26:19
I need at least --nmt and --tmn to customize quality & bitrate. These should definitely be kept.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-02 21:26:48
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-02 21:28:22
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: NickSD on 2002-06-02 22:44:17
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...
Title: What is your instance regarding Musepack SV8 switches?
Post by: kdo on 2002-06-02 23:56:18
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Q! on 2002-06-03 00:28:01
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: TrNSZ on 2002-06-03 02:21:57
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: ssamadhi97 on 2002-06-03 13:14:48
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?)
Title: What is your instance regarding Musepack SV8 switches?
Post by: auldyin on 2002-06-03 13:23:46
Hi,
Transcoding switch would be a good idea.

auldyin
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-03 18:21:13
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-03 18:52:48
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: vladimirovich on 2002-06-03 19:26:12
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).
Title: What is your instance regarding Musepack SV8 switches?
Post by: Garf on 2002-06-03 19:47:49
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: JohnV on 2002-06-03 20:24:05
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?
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-03 22:02:16
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?
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-03 22:08:49
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-03 22:09:59
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: JohnV on 2002-06-03 22:48:32
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?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Ruse on 2002-06-04 02:55:01
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".
Title: What is your instance regarding Musepack SV8 switches?
Post by: Ruse on 2002-06-04 03:20:23
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?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Ruse on 2002-06-04 03:34:07
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?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-04 04:11:26
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Ruse on 2002-06-04 04:42:10
Yes, this is well thought out in itself, but it would seem to me this is because of poor managemnt of the Lame developemnt process, not a fault of the switch availability.

Klemm has control over the developemnt of mpc, not a developemnt group (as far as I know). The switches in mppenc are all core functionality switches, and they are far less numerous than in Lame. It should be quite feasable to provide  for user adjustment of these small group of switches in a failsafe manner, and promote the presets as the usual manner in which mppenc is used.
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-04 10:07:27
Ruse and JohnV, I'll try to answer all your questions.

I was using the latest version of Frank's Encoder at the time, I don't recall the date, but it was sometime back in February if I'm not mistaken.

Using Audiograbber (I hadn't yet switched to EAC) I ripped track 1 to wav off the Time Out album which was brand new and still in mint condition.

I encoded and decoded back to wav using standard, xtreme, and insane presets (I mispoke and said it was braindead before)

Using Cool Edit Pro I lined up all four files and cut them into 30 second passages.  I randomly selected the various 30 second blocks and arranged them end to end to create the entire song from various 30 second samples.  I wrote the splices back out as a wav file.

I then burned a CD with the original wav as track 1, the three preset encodes, and then the splice version.
That CD is what I took over to ListenUp.

Equipment List:
Mark Levinson No. 39 CD player ($6K)
Mark Levinson No. 360S Preamp ($7500)
Mark Levinson No. 336 Dual Monoblock Amplifier ($10K)
B&W Nautilus 800 ($16K)
Not including the speaker cable, which was probably another $500 at least, that's $39,500.  The CD player and Preamp have all kinds of features designed to give the best sound possible, ie. jitter reduction and all kinds of technomarketing hype.

We dropped the CD in, and I first played the original wav track as a baseline.

I then played the splice track and asked him if he could identify a difference between the splices.  At the time I had the splice order on a piece of paper that I didn't show him, and he correctly identified the sections as better or worse than the preceeding section through the whole song.  Statistically it could have been a fluke, but without guidance from me, he identified 13 different sections.  I'm not saying it was a blind listening test, but it would be repeatable, and it was enough to convince me that there was something to what he was hearing.

As for me, I couldn't hear any hugely distinct differences and any differences I could "hear" might have been perception from having the list of splices in front of me.  I wouldn't exactly describe my own hearing as "golden" though, far from it really, so I don't think my own opinion weighs much.
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-04 10:11:41
Quote
Originally posted by Ruse
Yes, this is well thought out in itself, but it would seem to me this is because of poor managemnt of the Lame developemnt process, not a fault of the switch availability.

Klemm has control over the developemnt of mpc, not a developemnt group (as far as I know). The switches in mppenc are all core functionality switches, and they are far less numerous than in Lame. It should be quite feasable to provide  for user adjustment of these small group of switches in a failsafe manner, and promote the presets as the usual manner in which mppenc is used.


Very much agreed.  Lame has more significant issues than the number of switches. 

We're not asking that Frank add any switches either, we're simply asking that we not loose any functionality from the previous version.  If you want to drop some switches, how about dropping insane, since by Frank's admission it was actually created to give the best "looking" output with spectral analysis instead of giving the best "sounding" output.
Title: What is your instance regarding Musepack SV8 switches?
Post by: maciey on 2002-06-04 10:34:23
@gdougherty: wasn't  the CD mastered (normalized) to 98% or like this? If that -  this could be the cause - the listener may have (with his good hearing) indentified clipped (encoded-decoded) vs. non-clipped (original) parts... so maybe run a replaygain analysis on the encoded vs. non-encoded track?

Another thing that I think of is that You could repeat this test (if you can't convince your listener to ABX)wiht uneven splice lengths - not all splices 30 sec but, say, first 15 , second 23 etc...
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-04 11:10:59
Quote
Originally posted by Ruse
Yes, this is well thought out in itself, but it would seem to me this is because of poor managemnt of the Lame developemnt process, not a fault of the switch availability.


But it is because of the fact that these switches are maintained (to the detriment of other tasks since this is wasteful in both time and effort), and not dropped when they are unnecessary (same as many of the MPC switches) that continues this situation.  Yes that is poor management, but the thing is, you people are complaining about Frank doing the right thing here by removing these switches -- a sign of good management. 

Quote
Klemm has control over the developemnt of mpc, not a developemnt group (as far as I know).


Andree still has some say and I believe maybe 1 or 2 other people do also.. not entirely certain on that, but MPC isn't solely Frank's project.

Quote
The switches in mppenc are all core functionality switches, and they are far less numerous than in Lame.


How do you define "core functionality" switches?  Is something like the adjustability of the adaptive noise shaping a "core switch"?  How about the ath curve or something else?  If so then so are the ath adaptive switches, the noise shaping switches, the psymodel switches, etc in LAME.  There's really no difference here, the switches in LAME also affect the "core", if you define that as the encoding engine itself.

Granted, they are less numerous now, but things get out of hand over time.  The way to prevent this is to keep things in check and relevant as you go.  I think this is what Frank wants to do by removing some of the switches, and I think it is a good thing.

Quote
It should be quite feasable to provide  for user adjustment of these small group of switches in a failsafe manner, and promote the presets as the usual manner in which mppenc is used.


I do agree on this.  I think the best suggestion so far as been to adopt a system similar to the vorbis -q scale.
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-04 11:34:37
Quote
Originally posted by maciey
@gdougherty: wasn't  the CD mastered (normalized) to 98% or like this? If that -  this could be the cause - the listener may have (with his good hearing) indentified clipped (encoded-decoded) vs. non-clipped (original) parts... so maybe run a replaygain analysis on the encoded vs. non-encoded track?

Another thing that I think of is that You could repeat this test (if you can't convince your listener to ABX)wiht uneven splice lengths - not all splices 30 sec but, say, first 15 , second 23 etc...


I made no modifications to the original wav, there were only the encoding steps after ripping the wav.  Time Out was made before the days of heavy mastering compression and produces no internal clipping errors.  Correctly identifying 13 splices, even or not, is good enough to convince me that it's more than a fluke.  I'd feel a bit odd going back and asking him to repeat the proceedure, though I do love listening to the equipment.  I'm really just throwing it out there as an example, as I said, it was enough for me.

G
Title: What is your instance regarding Musepack SV8 switches?
Post by: Ruse on 2002-06-04 11:57:11
Quote
Originally posted by gdougherty
Statistically it could have been a fluke, but without guidance from me, he identified 13 different sections.  I'm not saying it was a blind listening test, but it would be repeatable, and it was enough to convince me that there was something to what he was hearing.

As for me, I couldn't hear any hugely distinct differences and any differences I could "hear" might have been perception from having the list of splices in front of me.  I wouldn't exactly describe my own hearing as "golden" though, far from it really, so I don't think my own opinion weighs much.


You say he correctly identified 13 different sections: how many sections were there in the splice? Were the encoder quality presets randomised, or did you start with the wav and work systematically through the quality presets --standard, --xtreme, --insane?

Did he identify the full length, unspliced encoded tracks as being inferior to the wave?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Frank Klemm on 2002-06-04 15:28:34
Quote
Originally posted by Dibrom

But it is because of the fact that these switches are maintained (to the detriment of other tasks since this is wasteful in both time and effort), and not dropped when they are unnecessary (same as many of the MPC switches) that continues this situation.  Yes that is poor management, but the thing is, you people are complaining about Frank doing the right thing here by removing these switches -- a sign of good management. 

Andree still has some say and I believe maybe 1 or 2 other people do also.. not entirely certain on that, but MPC isn't solely Frank's project.

How do you define "core functionality" switches?  Is something like the adjustability of the adaptive noise shaping a "core switch"?  How about the ath curve or something else?  If so then so are the ath adaptive switches, the noise shaping switches, the psymodel switches, etc in LAME.  There's really no difference here, the switches in LAME also affect the "core", if you define that as the encoding engine itself.

Granted, they are less numerous now, but things get out of hand over time.  The way to prevent this is to keep things in check and relevant as you go.  I think this is what Frank wants to do by removing some of the switches, and I think it is a good thing.

I do agree on this.  I think the best suggestion so far as been to adopt a system similar to the vorbis -q scale.


Exists since 1.05a. I removed a lot of "do this exactly in this mode" which changes
bitrate again and also changes the meaning of the profiles.
Quality setting selects bitrate between typical 30 kbps and 300 kbps.

--minSMR was removed, it diturbs the current model.

Basic (quality) settings are:

Code: [Select]
  --quality    x.x         (0.0...10.0, dflt: 5.0)

 --maxbitrate xxx         (56...2048, dflt: 2048)

 --maxlatency x.xx        (0.05...oo, dflt: oo)

 --minbitrate xx          (0...128, dflt: 0)      (may be!)


Secondary (quality) settings are:

Code: [Select]
  --stereoquality   x      (0...10, dflt: 5, stereo imaging quality against sound quality)

 --bandwithquality x      (0...10, dflt: 5, more encoded audio bandwith against encoding noise)

 --temporalquality x      (0...10, dflt: 5, more temporal resolution against better TMN)


Tertiary (quality) settings are:

Code: [Select]
  --psychodatabase x.psy   (load alternative psycho database, ca. 2 MByte large)
Title: What is your instance regarding Musepack SV8 switches?
Post by: Jan S. on 2002-06-04 15:40:31
cool!!!

now all the insano tweakers can tweak the hell out of it and it will still be good....if the quality is saved in the file that is
Title: What is your instance regarding Musepack SV8 switches?
Post by: ancl on 2002-06-04 15:50:31
Great!! 
Title: What is your instance regarding Musepack SV8 switches?
Post by: atherean on 2002-06-04 15:52:06
Great news, a quality scale, thanks, Frank
Now the only question i have is who's the alternative psycho?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Jan S. on 2002-06-04 15:54:09
Quote
who's the alternative psycho


Frank Klemm, Andree being the original psycho?
Title: What is your instance regarding Musepack SV8 switches?
Post by: AgentMil on 2002-06-04 15:57:40
LoL!!

Well Jan S. those two are the best "psychos" I have ever seen, they created one of the best audio coding format ever!

On a more serious note:

When is 1.05a coming out?

Love your work Frank keep it up and you to Dibrom!!

Cheers
AgentMil

PS. Guess no need for that command line anymore.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Jan S. on 2002-06-04 16:04:42
yeah, I agree.
I love mpc... and even more now.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Frank Klemm on 2002-06-04 16:13:08
Quote
Originally posted by AgentMil
LoL!!

Well Jan S. those two are the best "psychos" I have ever seen, they created one of the best audio coding format ever!

On a more serious note:

When is 1.05a coming out?

Love your work Frank keep it up and you to Dibrom!!

Cheers
AgentMil

PS. Guess no need for that command line anymore.


Current version is 1.05e.
Title: What is your instance regarding Musepack SV8 switches?
Post by: AgentMil on 2002-06-04 16:17:25
Thanks Frank

But when will that version be available to the public?

Cheers
AgentMil
Title: What is your instance regarding Musepack SV8 switches?
Post by: CiTay on 2002-06-04 16:29:03
I'm very relieved. This was a big step forward.
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-04 16:34:33
Quote
Originally posted by Ruse


You say he correctly identified 13 different sections: how many sections were there in the splice? Were the encoder quality presets randomised, or did you start with the wav and work systematically through the quality presets --standard, --xtreme, --insane?

Did he identify the full length, unspliced encoded tracks as being inferior to the wave?


Go back and carefully read my posts, you're misunderstanding what went on.  What I described is all that happened.  The song is just over 6.5 minutes, giving 13 splices each from a randomly selected bitrate.  I played only the original and the version made up of splices.

G
Title: What is your instance regarding Musepack SV8 switches?
Post by: YinYang on 2002-06-04 16:37:32
Whee..

And I've alreday found my new commandline


--quality (pi-0.004i+0.005*earthsdiameter/2lightyears+AgeofNataliePortman/AgeofCameronDiaz)
Title: What is your instance regarding Musepack SV8 switches?
Post by: -=Ducky=- on 2002-06-04 16:44:45
Frank, you and all the other people who work on mpc keep amazing me!!!!

Everyone was discussing what to do or not to do on the forum, but your switches sound the most logical and easy to use.

To put it in other words : great work, keep it up!!!

But some questions : what will happen to the names like standard, xtreme and insane in the current mpcfiles????

I really would like to convert all my mpc's SV7 to SV8 when it becomes available, I hope the backwards compatibility is still there to "lossless" convert to SV8.
I guess it is, but still wanted a confirmation from you.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Gecko on 2002-06-04 17:31:39
I have recently voted to keep the switches like they are. I was acting on impulse thinking: who the hell do you think you are, to tell me how to encode my music?! I kept thinking and would have rather voted (if it were available): wait and see. We all didn't know what was planned and were arguing based on pure speculation about the future switches. My main concern was that I would be limited to a very small amount of qualities/bitrates. Now that I see what is coming I would like to say: congrats, Frank, throw away those old switches!

I have difficulty understanding the secondary quality switches though. It sounds like you are making a tradeoff each time, sacrificing quality on one end while gaining quality on the other. Is this the way it's supposed to work? Couldn't you have switches like "tonality precision" or "impulse precision" which do not negatively affect other aspects of the encoding process? Please shed some light on this.

I also see a slight difficulty with the quality values, which I guess cannot be avoided.  People will be asking: what do the q settings represent? What value do I need to use, if I want xyz enabled/disabled? etc.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Frank Klemm on 2002-06-04 17:32:02
Quote
Originally posted by Jan S.
cool!!!

now all the insano tweakers can tweak the hell out of it and it will still be good....if the quality is saved in the file that is


You haven't the slightest idea about the complexity of these tables.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Jan S. on 2002-06-04 17:39:31
Quote
You haven't the slightest idea about the complexity of these tables.


nope.
Title: What is your instance regarding Musepack SV8 switches?
Post by: gdougherty on 2002-06-04 18:04:05
To attempt an answer for some users' questions, here's my take on the switches.
Anybody else have better guesses?  Anybody in the know, care to clarify where I'm wrong?
Quote
Originally posted by Frank Klemm  
Exists since 1.05a. I removed a lot of "do this exactly in this mode" which changes
bitrate again and also changes the meaning of the profiles.
Quality setting selects bitrate between typical 30 kbps and 300 kbps.

--minSMR was removed, it disturbs the current model.

Basic (quality) settings are:

Code: [Select]
  --quality    x.x         (0.0...10.0, dflt: 5.0)

 --maxbitrate xxx         (56...2048, dflt: 2048)

 --maxlatency x.xx        (0.05...oo, dflt: oo)

 --minbitrate xx          (0...128, dflt: 0)      (may be!)

So generally we'll use these to adjust our files based on our goals.  Most people would simply use the --quality switch, and not bother with the rest unless their specific application needed it.  This would be 1.05 at its simplest.  Basically replacing the non-tweaked presets with quality levels.  Looks like CBR is possible from 56-128Kbps.
Quote
Originally posted by Frank Klemm  
Secondary (quality) settings are:

Code: [Select]
  --stereoquality   x      (0...10, dflt: 5, stereo imaging quality against sound quality)

 --bandwithquality x      (0...10, dflt: 5, more encoded audio bandwith against encoding noise)

 --temporalquality x      (0...10, dflt: 5, more temporal resolution against better TMN)

More tweaking options, I'd imagine that the quality scale also moves these at the same intervals since 5 seems to be the default for everything.  Again, most people will leave these alone and probably use the quality scale.
Quote
Originally posted by Frank Klemm  
Tertiary (quality) settings are:

Code: [Select]
  --psychodatabase x.psy   (load alternative psycho database, ca. 2 MByte large)

And the final and most likely least frequently modified setting, switching to a differenct psycho accoustic model perhaps?  I guess this means we can expect different models to come out with SV8?  Perhaps different models focused towards low and high bitrate applications?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-04 22:00:20
Quote
Originally posted by CiTay
I'm very relieved. This was a big step forward.


I agree.

Good job Frank!
Title: What is your instance regarding Musepack SV8 switches?
Post by: lucpes on 2002-06-04 22:19:56
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?
Title: What is your instance regarding Musepack SV8 switches?
Post by: Uosdwis R. Dewoh on 2002-06-04 22:22:09
Indeed - great job! Looking forward to putting it to use! Puts that other thread in a new perspective, too.

/ Uosdwis
Title: What is your instance regarding Musepack SV8 switches?
Post by: NickSD on 2002-06-04 23:09:44
I think this poll should be closed... Since we have the q-scale now, everyone seems to be happy.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-04 23:17:37
Quote
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: andy2kxp on 2002-06-05 00:38:15
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-05 00:46:05
Quote
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.

Quote

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


Probably.
Title: What is your instance regarding Musepack SV8 switches?
Post by: ssamadhi97 on 2002-06-05 00:57:13
Quote
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)
Title: What is your instance regarding Musepack SV8 switches?
Post by: vladimirovich on 2002-06-05 08:01:53
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Garf on 2002-06-05 10:23:39
Quote
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.

Quote
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-05 11:27:19
Quote
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: smg on 2002-06-05 13:08:01
Quote
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: Dibrom on 2002-06-05 13:51:35
Quote
Originally posted by smg


I won't respond to that comment


You just did.
Title: What is your instance regarding Musepack SV8 switches?
Post by: David Nordin on 2002-06-05 14:32:05
Quote
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: Volcano on 2002-06-05 15:12:48
Quote
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: GeSomeone on 2002-06-05 16:35:54
Quote
Originally posted by Volcano
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.


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

edit: contra
Title: What is your instance regarding Musepack SV8 switches?
Post by: Volcano on 2002-06-05 16:47:00
Quote
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
Title: What is your instance regarding Musepack SV8 switches?
Post by: R.A.F. on 2003-09-12 20:26:16
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.
Title: What is your instance regarding Musepack SV8 switches?
Post by: rjamorim on 2003-09-12 21:59:20
I wonder how did you find this thread to start with
Title: What is your instance regarding Musepack SV8 switches?
Post by: R.A.F. on 2003-09-12 22:36:13
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.