I am new to MPC went from Mp3 To Lossless now reading this forum about MPC and like what I've read so far. I am trying to achieve the very best quality I can don't really understand the switches nor how to tweak them. I've just been copy other peoples switches and trying them. I coped this

%l--etc%l%h--braindead --ans 0 --ms 0 --nmt 32 --tmn 40%h %s

Encoded a File with an average bitrate of 516kbs. Is this quality or just a larger bitrate that adds nothing?

This is called overkill.

Most people should be 99,99% fine with standard.

If you are unsure, go with extreme. Just extreme, no more switches.

If you want huge bitrates like that one, use Monkey's Audio.

Regards;

Roberto.

I understand that is an overkill but I'm curious if that kbs equates to better quality. even if i can't hear it i'd like to know it was still there.

It should be better quality, but I doubt it's noticeable.

Anyway, if you are confortable with such huge bitrates, I would seriously recomment that you try lossless. Then, ALL the quality will be there, and the bitrate wouldn't increase much more than 516kbps.

Regards;

Roberto.

The --ms 0 switch will degrade quality... it was discussed earlier on this board.

But don't just remove that switch... remove everything and stick with --standard (what Andree, the creator of Musepack, uses) or --xtreme (if you have strangely good hearing or you plan on transcoding to mp3 for a portable device, if perhaps the extra headroom makes a difference when transcoding).

I did some tests with MPC transcoding, and I could never perceive a difference between WAV --> MPC-standard --> Lame alt-preset standard and just WAV --> alt-preset standard. On the few samples I could ABX, both MP3 samples were just as difficult to distinguish from the original.

All of these MPC commandline tweaks floating around are the result of curious users who want to feel like their MPC's are "their own" (I used to do this myself a bit). This is all well and good, and it's important to continue investigating ways of improving quality, but MPC has already been tweaked and tuned about as much as is possible (in my opinion and probably the opinions of some heavy hitters on this board), and those tweaks are stored in the presets.

As long as you don't touch some of the more obscure switches in mppenc, and you just increase --nmt and --tmn, you won't hurt the audio quality, you'll just bloat the bitrate more than necessary.

Sure, you'll have an extra safety margin for repeated transcodes and the once-in-a-lifetime annoying artifact, but tweaking MusePack's default settings way past what is necessary is kind of like wearing a bomb suit and an innertube to the office every day

Edit: it would be nice if I could get the MPC creator's name right...

omg...this is an absurd line a la citay or something [hey citay!] i see no reason in any situation to go above "--insane --minSMR 0 --nmt 12 --tmn 32" but i would stick with just "--insane --minSMR 0" for normal encodes.

whoever thinks that these are unnecessary bloat better not have a single mp3 file on their computer.

...i thought so.


and if you don't want to have to worry about "tweaking" etc., you can always just use psytel aac with "-archive"...which is what i have been doing lately and am quite happy with it. [damn pushy brazilians]



so would using ogg vorbis be kind of like being completely oblivious that you are naked at the office every day?

...or perhaps naked while holding a leaf-blower?

...or maybe one of those expensive weed-wackers?

...maybe if i post this commandline some poor guy will be using it soon, too:

"well, i think this is the best commandline for musepack. i don't care what others say"

--insane --ltq ank --nmt 99 tmn 99 --ms 0

...maybe if i post this commandline some poor guy will be using it soon, too:

"well, i think this is the best commandline for musepack. i don't care what others say"

--insane --ltq ank --nmt 99 tmn 99 --ms 0

Have you forgotten --ans 0?

Thanks Jeff.

hmm. I've seen Monkey's Audio go as high as 1100kbps..

I'd suggest to just go with --xtreme unless you can reliably abx the difference from the pure wave file...

why not just stick with --standard for normal encodes? After all, that's why it's "standard". ~170kbps for something that's transparent to my ears ~100% of the time is a bargain.

Dibrom has argued that --standard is transparent "99.999%" of the time to most listeners and that anything more than --xtreme will be overkill for almost any sound source. Garf has claimed that, with the few samples he's seen that fail transparency tests when encoded by Musepack, they fare just as well with --standard as they do with --xtreme.

(I'm paraphrasing from this old thread... I hope I haven't mis-represented anyone, but if you want to know the exact words they said, just check the link.)

Yes, there are certain clips where the golden ears can go from "barely noticeable" to "undetectable" by boosting --nmt a couple of notches.
Personally, if I was concerned about these special cases popping up, I'd either take care of them on a case-by-case basis or simply use a lossless encoder, since going from --standard to --insane --nmt 16 --tmn 32 will only make samples transparent 99.999% --> 99.99999% of the time, but it will double my bitrates, halving the amount of music I can store on my hard drive. If that 0.001% makes a difference to you, won't the 0.00001% also bother you too?

All these paranoid discussions about tweaked commandlines made me encode all my CD's using --insane a while back. Now I have to go back and re-rip and re-encode using --standard because I'm out of hard drive space and I realize that I can't hear a difference between the two after all. I just don't want other people to make the same mistake I did unless they can prove that they hear the benefits of a tweaked commandline.

[b]This is an argument I've never really understood; if old MP3's needed to be encoded with CBR 256 to sound transparent 99% of the time, then some people think that --alt-preset extreme (~256kbps) is needed to achieve the same level of transparency, which simply isn't true. Likewise, just because --alt-preset extreme takes 256kbps to encode transparently 99.9% of the time doesn't mean Musepack needs to be boosted to 256kbps to get that level of transparency.

[b]Vorbis is like wearing a tie on Fridays. Maybe it helps you pick up on the good-looking secretaries, or maybe it just makes you a nerd.

Thanks to those who tried to be helpful and explain why not to tweak that high. To those who think they have to be sarcastic to us new users just to prove they may have some knowledge of audio compression just remember at one time you were where i'm at now......
But thanks again. I can't believe the amount of Knowledge I've pick up on this forum.

i am well aware of the thread...

when i archive [with the thought i am going to transcode, etc.] i use a "--insane --minSMR 0" commandline.

it is acceptable to me to have a 50kbps bloat [as you call it] to have guaranteed perfect archiving. my average kbps of mpc files is 220 kbps...that ain't shabby.

i don't worry about hd space because when i get that much files i burn to cd...and use them quite regularly. i look forward to the day when i can pop one into a dvd player, but *sigh* it probably will never be...

i don't plan on sharing my files [no broadband] so it is really a non-issue of what i use personally. if i were encoding to share i would use whatever the community used [which i think is "--extreme"]

by "normal" i meant what i usually encode [punk, rock, etc.] sometimes i encode spoken word and comedy albums at "--radio" and sometimes i encode albums that i won't ever have again at "--insane --minSMR 0 --nmt 11 --tmn 32" and have never gone above "--insane --minSMR 0 --nmt 12 --tmn 32"... which is comparable to the bitrate of insane and braindead

i haven't personally experienced, nor heard of someone experiencing, an artifact at --nmt 12 or above - but have below that...ask mith and he will tell you about his experiences if you wan't someone else's response besides mine.

i am quite aware that mpc will be good at --standard and need not hit the 256kbps mark to achieve great quality "99.99999999999999999999999999999999999999999999999999999999999999999999999999%" of the time.

and i don't wan't to take care of them on a case by case basis. if you have all that time to listen intensively to every file that you encode before deleting the source you must not do it as often as i.

and don't bitch to me about using lossless...4 times the filesize of "--insane --minSMR 0" is not the next step "IMHO"

btw, you encoded your entire cd archive with a commandline that was using all that bloat on the full bandwidth, much of which the human ear cannot ever hear...that is why you can't tell the difference.

and dibrom wouldn't argue that because it is a guess, and i beleive he "argued" it with the sole purpose of it being a guess and not to be quoted by others trying to make it an arguement.

garf has stated previously that [paraphrase] "usually the problem samples at --standard are often not corrected at --extreme" which leaves the possibility that either:
1. the file necessitated a more intense commandline
2. the format is doomed to fail on these samples

it is interesting to me that you would bail so quickly


later
mike

Well this is kind of old moot as we're speaking of VBR
To summarize this to some reasonable advise (how to start encoding with mppenc):
- don't use options you don't know what they mean
- in general use --standard
- if you really need extra headroom (quality wise) to sleep at night, use --xtreme

- Keep reading this forum to learn and discuss other details after that
--
Ge Someone

Hi xmixahlx :naughty:

Tell you what, i noticed a completely different problem of --standard and sometimes even --xtreme.

On fairly noisy recordings, mostly old songs or some live recordings, the "intelligent lowpass" cuts off too much noise in the higher frequency regions. I first noticed it on my speakers, i have yet to ABX this. Now, you might say (maybe righteously so) that this is an improvement of quality. Yes, the perceived quality might be better, but this is not about removing anything to make the song sound better, this is about accurately reproducing the original, and nothing else. When i have more time, i will do an ABX test, and apologize if my mind played tricks on me.

Also, since the last time i posted my MPC line, it has changed quite a bit. I am now using "--insane --minSMR 0" for more uncritical material (defaults to --nmt 10 in the newest encoder IIRC), and "--insane --minSMR 0 --nmt 12 --tmn 26" for critical material.

I am now using "--insane --minSMR 0" for more uncritical material (defaults to --nmt 10 in the newest encoder IIRC), and "--insane --minSMR 0 --nmt 12 --tmn 26" for critical material.
Why not use minSMR3 instead of --minSMR 0?

Don't throw anything at me. But, what does --ltq ank do? And, can one use that in conjunction with --minSMR 0? And, if so what might the encoding string look like? Thanks Jeff

Minimum SMR is defaulted to 3 dB in --insane. I set it to 0 dB to enable the "intelligent lowpass" (don't know any better name) of --standard and --xtreme. With 3 dB, it wouldn't use a lowpass at all. So --minSMR 0 lowers quality, but also decreases bitrate.

BTW, with uncritical material, i mean music that i listen to when i'm sitting in front of the PC.




"--ltq ank" is the default hearing threshold in quiet for --standard. For --xtreme, --insane and --braindead, a different (sometimes lowered) curve is used, "--ltq fil". This curve defines at which point the tested person can hear a pure sine wave, over the frequency spectrum from usually 20 Hz - 20 KHz. The lower the curve, the more sensitive the hearing is. --ltq ank is less sensitive than --ltq fil, making the encoder basically leave out more signals and lowering bitrate & quality.

Speaking of command lines: this one guy in MPC shariing community encodes everything with

--xtreme -ms 0 -nmt 9 -ltq_gain -5 -v

So, can someone tell something about that command line, cause my knowledge on the subject is very limited. :-}

Thanks.

First off, these switches, except --xtreme, do nothing in recent encoder versions. The corrected line would be "--xtreme --ms 0 --nmt 9 --ltq_gain -5 --verbose".

"--ms 0" means that he uses Stereo instead of Joint Stereo (ms = Mid/Side aka JS). One of the MPC devs confirmed that this can *decrease* quality. "--nmt 9" raises NMT to 9 dB (default for --xtreme is 8 dB). That is a quality improvement: Allows less noise. "--ltq_gain -5" lowers the hearing curve of "--ltq fil" by 5 dB, also a quality improvement. Lower means that more of the original content will be preserved. The question remains if this is really a better quality to the listener, since --ltq fil is fairly sensitive. Nonetheless, --insane uses --ltq_gain -6 by default. "--verbose" just makes the window display more info during encoding.

this is like the middle ground of "--extreme" and "--insane --minSMR 0"

although i wouldn't use "--ms 0" in any situation...well, maybe if _ I _ recorded something myself in stereo [live concert, etc.] and wanted to encode it with completely seperated channels.

one of musepack's great features is using m/s.

...the commandlines never end


later
mike

Here's the thread where Frank Klemm (or JohnV) says that not only will using --ms 0 increase bitrates because it disables that whole mid/side thing, but it also disables Binaural Masking Level Depression (BMLD) threshold calculations (whatever those are), which I guess means --ms 0 will always sound worse than the default. In other words, I think that discussion concluded that mid/side coding should never be disabled, even if the user doesn't care about the bitrate bloat. I couldn't really follow the discussion, so I'll just accept the conclusion

To respond to your other posts:

QUOTE

[b] btw, you encoded your entire cd archive with a commandline that was using all that bloat on the full bandwidth, much of which the human ear cannot ever hear...that is why you can't tell the difference.

it's true I shouldn't have used --insane with the default --minSMR, but I started using it because mithrandir made some comments about how the extra bandwidth might improve transcoding (although I haven't read about listening tests that substantiate them). The logic made sense to me as well, although now I'm not sure if I will ever hear that difference.

QUOTE

[b]and i don't wan't to take care of them on a case by case basis. if you have all that time to listen intensively to every file that you encode before deleting the source you must not do it as often as i.

I agree with you, if you're talking about a CD you won't always have easy access too. But for me, I have all my CD's easily accessible, so if one day I notice an artifact on one of my --standard encodes, I can just re-encode it and be on my way in minutes. Of course, I'm not sure I'll ever notice a difference between the original and the compressed because I rarely (if ever) listen to my CD's uncompressed; I buy them, convert them to MPC, and then put them back in storage

QUOTE

[b]
it is acceptable to me to have a 50kbps bloat [as you call it] to have guaranteed perfect archiving.

But that's just it; there's no such thing as "guaranteed perfect" with lossy coding. I guess it depends on a person's threshold for what % of their files encode transparently; for me, I don't care if I can barely ABX a couple seconds from 1% of my encodes. Hell, I still listen to downloaded CBR MP3's, so there's no reason for me to be too picky. Your ability to detect artifacts is probably better than mine, so while I achieve my needs with --standard, you might need --insane --minSMR 0 to get 99% transparencyl. So what % transparency do you get with your tweaked commandline? 99.99%?

Anyway, my arguments about % transparency are silly, so I won't discuss them any more. [b]What I would like to discuss are problem samples for MPC.

I don't doubt that you can ABX certain clips with --nmt less than 12 (at least with older encoders) but I'd like to see if I can hear differences on those clips. If I can (which is unlikely), I guess it means I should use a super-powered commandline for CD's I won't have access to in the future but I also don't want to convert losslessly. Please, if you can, make these clips available. Also, have you tried these "killer clips" with newer versions of mppenc? (The only clip I've ever been able to ABX with --xtreme is castanets, and I wonder if new tunings in the last five months have changed even that.)

And another thing about problem samples; do you have a fairly good-sized set of samples that you can ABX with --standard? I think there's a distinction between "killer clips" and general recording that shouldn't be difficult to encode, and if I can ABX these general clips, that would make me much more inclined to use a higher-quality commandline than --standard.

Hi Guys,
I'm 100% new to MPC and am seriously considering archiving a very large CD collection.

However, I do listen a lot on a portable and would need to transcode to MP3 (I'm familiar with MP3Gain etc for handling MP3 files).

So question is, do I encode with --extreme or --insane bearing in mind that the main purpose is archiving.

Thanks,
auldyin


EDIT I use EAC in secure mode for ripping so I take this whole business seriously

An important information: Are you going to use your portable to really listen to the musics, with a good pair of headphones, in a quiet room?

Or will you use it while jogging, or while on the bus?

If it's the second option, I would see no problem in encoding to MPC -standard (-extreme if you have really good hearing and like problematic tunes) and later transcoding to ABR128.

Regards;

Roberto.

Hi Roberto, (got the correct name this time)
The portable is only used when on the bus, jogging etc.

However, at some stage I'm sure that I'll want to decode my archived stuff, and burn it to disc (compilations, friends etc). Thus I need the best quality MPC files, without going to braindead.

Hope this is clear,

auldyin

Well, most people can't find any artifacts in --standard, even with difficult tunes.

If you want to be sure, use --xtreme.

IMO, anything above that is overkill. A waste of bits. Unless you listen to really troublesome music, or has fantastic hearing.

Regards;

Roberto.

edit: -standard -> --standard, -extreme -> --xtreme... roberto, you should know this by now!

edit2: Blah! I'm no MyOozePacker, CiTay. you should know this by now!

For this kind of listening, yes. For making CDs from those MPCs, i'd add some more headroom, for example "--xtreme --nmt 10" or "--insane --minSMR 0".

Is augmented commandline recommended because artifacts can regularly be heard with "just" --xtreme, or because the extra --nmt usually remedies the rare case where Musepack fails, and doesn't cost many more bits? What test clips do you use to determine the maximum --nmt you (personally) will probably ever need for any transparent coding: some special clips, or just the standard codec-killers? Thanks for the tips!