Skip to main content ↑ ↓

Notice

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

Mppenc 1.14

Mppenc 1.14 is available at http://www.saunalahti.fi/cse/mpc/index.html.

Includes some bugfixes + supports direct encoding from wavpack and la.

Mppenc 1.14

Reply #1 –
Nice. Since there are no quality changes I assume it's safe to use...?

Mppenc 1.14

Reply #2 –
The encoder's console output says BETA rather than Alpha, so it is "safe" to use.

Mppenc 1.14

Reply #3 –
Hee, hee, how long has this been in the encoder?

WARNING:
  There still occured 1 SCF clippings due to a restriction of StreamVersion 7.
  Use the '--scale' method to avoid additional distortions. Note that this
  file already has annoying distortions due to slovenly CD mastering.

Mppenc 1.14

Reply #4 –
Quote
Hee, hee, how long has this been in the encoder?

WARNING:
  There still occured 1 SCF clippings due to a restriction of StreamVersion 7.
  Use the '--scale' method to avoid additional distortions. Note that this
  file already has annoying distortions due to slovenly CD mastering.

mithrandir do we need to use --scale when using --standard or --xtreme?
Allegari nihil et allegatum non probare, paria sunt.

Mppenc 1.14

Reply #5 –
Quote
mithrandir do we need to use --scale when using --standard or --xtreme?


The message mithrandir posted is about Scalefactor clipping that couldn't be solved, not even with the --xlevel switch. This is an indication that the song was so badly mastered that it really would need audio restoration. You can't save these kind of signals with scaling, because the damage has already been done in the mastering studio. The best you can do right now is using --xlevel with the quality setting, like this: "--quality 6 --xlevel". Scaling (even more so, normalizing in EAC) should be avoided.

Mppenc 1.14

Reply #6 –
From the link above, what is the difference between all the mppdec versions? What is mpdec16. mppdec24, etc.?

--Rizban

Mppenc 1.14

Reply #7 –
Quote
From the link above, what is the difference between all the mppdec versions? What is mpdec16. mppdec24, etc.?

Those are so called high quality decoders. They support noise shaping + dithering and various output bitdepths. Mppdec16 outputs 16 bit data, mppdec24 24 bit and mppdec32 32 bit.

Mppenc 1.14

Reply #8 –
Quote
Those are so called high quality decoders. They support noise shaping + dithering and various output bitdepths. Mppdec16 outputs 16 bit data, mppdec24 24 bit and mppdec32 32 bit.

How about a Winamp plugin with 24 bit support?

Mppenc 1.14

Reply #9 –
Quote
How about a Winamp plugin with 24 bit support?

There will be for Winamp 2, for Winamp 3 already is.

Mppenc 1.14

Reply #10 –
Quote
...Since there are no quality changes I assume it's safe to use...?

hum...
are 'beta' safe to use? good question...
i just though betas were released for testing purposes 

i noticed that files encoded with 1.12 -beta- (with 1.14 -beta- too?) had  bitrates lowered by 5 kbs in comparison with 1.1 release. this is quality change, isn't it?
so still using the release (1.1)...

cu,
pipo.

Mppenc 1.14

Reply #11 –
I get this message when I run the Linux binary (1.14):

MPC Encoder  1.13i  -Beta-  © 1999-2002 Buschmann/Klemm/Piecha

And when I decode a file encoded with this version I get:

91.1 kbps,    3:39.97, SV 7.1, Profile Unstable/Experimental (--Alpha-- 1.13) <-- thumb
136.4 kbps,    3:39.97, SV 7.1, Profile Unstable/Experimental (--Alpha-- 1.13) <-- radio
167.4 kbps,    3:39.97, SV 7.0, Profile Unstable/Experimental (--Alpha-- 1.13) <-- standard
188.6 kbps,    3:39.97, SV 7.0, Profile Unstable/Experimental (--Alpha-- 1.13) <-- xtreme
207.9 kbps,    3:39.97, SV 7.0, Profile Unstable/Experimental (--Alpha-- 1.13) <-- insane
229.2 kbps,    3:39.97, SV 7.0, Profile Unstable/Experimental (--Alpha-- 1.13) <-- braindead

I've used versions 1.1, 1.12 and 1.13a of the Linux decoder. Am I doing something wrong or this is not 1.14?

BTW, when I run decoder 1.13a it says:

MPC Decoder  SV7  1.12  3DNow/SSE  © 1999-2002 Buschmann/Klemm/Piecha/Wolf

Filesize & date is exactly the same as 1.12.  I suppose they're the same?

Cheers.

Mppenc 1.14

Reply #12 –
i assume i should go on using 1.1 

Mppenc 1.14

Reply #13 –
Quote
are 'beta' safe to use? good question...
i just though betas were released for testing purposes

Betas are safe to use.

Quote
i noticed that files encoded with 1.12 -beta- (with 1.14 -beta- too?) had  bitrates lowered by 5 kbs in comparison with 1.1 release. this is quality change, isn't it?
so still using the release (1.1)...

Yes, there have been improvements after version 1.1. Listening tests have showed that 1.1 is inferior in quality to more recent versions, and 1.14 is best so far.

Mppenc 1.14

Reply #14 –
Quote
I get this message when I run the Linux binary (1.14):

MPC Encoder  1.13i  -Beta-   © 1999-2002 Buschmann/Klemm/Piecha

[...]

I've used versions 1.1, 1.12 and 1.13a of the Linux decoder. Am I doing something wrong or this is not 1.14?

I'll ask Klemm to correct this issue.

Quote
BTW, when I run decoder 1.13a it says:

MPC Decoder  SV7  1.12  3DNow/SSE   © 1999-2002 Buschmann/Klemm/Piecha/Wolf

Filesize & date is exactly the same as 1.12.  I suppose they're the same?

I'll remove that decoder from my page. Pre 1.93j decoders have some nasty bugs and shouldn't be used.

Mppenc 1.14

Reply #15 –
Quote
I'll ask Klemm to correct this issue.

Thanks.

Quote
I'll remove that decoder from my page. Pre 1.93j decoders have some nasty bugs and shouldn't be used.

That means 1.93j is the recommended decoder? I thought it was only for testing (as 1.93j encoder is, according to your page)

Mppenc 1.14

Reply #16 –
Quote
That means 1.93j is the recommended decoder? I thought it was only for testing (as 1.93j encoder is, according to your page)

1.9x series have been recommended decoders for quite some time (by me). On my page it has always been stated that 1.9x can decode all stream versions, this was intended as a hint that no other decoder is needed . Now with page cleanup I keep recommended versions on top and removed links to old decoders.

Mppenc 1.14

Reply #17 –
Quote
1.9x series have been recommended decoders for quite some time (by me).

Didn't know about that. I suggest adding this info to the "List of recommended MPC settings". I'm running Linux and I often use mppdec for playback, so if "MPC 1.12 is the recommended version" I simply guess (wrongly) that it also applies to the decoder.

Thanks again.

Mppenc 1.14

Reply #18 –
Quote
Quote
mithrandir do we need to use --scale when using --standard or --xtreme?


The message mithrandir posted is about Scalefactor clipping that couldn't be solved, not even with the --xlevel switch. This is an indication that the song was so badly mastered that it really would need audio restoration. You can't save these kind of signals with scaling, because the damage has already been done in the mastering studio. The best you can do right now is using --xlevel with the quality setting, like this: "--quality 6 --xlevel". Scaling (even more so, normalizing in EAC) should be avoided.

Could you please explain why such an uncorrectable error occurs? How does a signal look like that --xlevel cant correct?

Mppenc 1.14

Reply #19 –
Quote
Could you please explain why such an uncorrectable error occurs? How does a signal look like that --xlevel cant correct?

it occurs because the people who master it (you know, when they make the cd) set the volume too high so that the it's the tracks on the cd that are clipping. in that case, mppenc can't do anything about it, since it doesn't have the information that's lost in the clipping. it probably looks like any other clipping... the problem is that it's in the input file and not from the encoding process. the latter is what xlevel fixes. there's a lot more explanation elsewhere on the forum, if you know what to look for (i don't really know, and i'm lazy, so i'll leave it up to you). maybe look for "Rush"? their last album was pretty bad, apparently.

Mppenc 1.14

Reply #20 –
Quote
maybe look for "Rush"? their last album was pretty bad, apparently.

Sure is.  (I think it was fewtch who first mentioned this article)

There are some graphs there that show extreme clipping on the CD, perhaps that's what theduke is looking for.

Mppenc 1.14

Reply #21 –
Quote
Quote

it occurs because the people who master it (you know, when they make the cd) set the volume too high so that the it's the tracks on the cd that are clipping. in that case, mppenc can't do anything about it, since it doesn't have the information that's lost in the clipping. it probably looks like any other clipping... the problem is that it's in the input file and not from the encoding process. the latter is what xlevel fixes. there's a lot more explanation elsewhere on the forum, if you know what to look for (i don't really know, and i'm lazy, so i'll leave it up to you). maybe look for "Rush"? their last album was pretty bad, apparently.

I have problems to imagine that. What does it mean when the volume is set too high? I know these graphs where one can see clipped signals but I don't really know the meaning. I haven't read any technical books on recording/etc. because a lot of the good books are in english which is too difficult for me not being an english native speaker and I wouldn't want to go too much into detail. I only want to know the basics (for now) and this is the case here.

So what is clipping? And from where on is a signal clipped? When its volume is above 0dB? Because resolution is 16bit and the signal is 'out of range'? Or am I going in a totally wrong direction?

Mppenc 1.14

Reply #22 –
Yes, a clipped signal is a signal that falls out of range.

Mppenc 1.14

Reply #24 –
Why does 1.14 lose the bolded text for the headers that 1.13g had? I think the bolding looks better.