Help - Search - Members - Calendar
Full Version: testing of the new MPC encoder
Hydrogenaudio Forums > Lossy Audio Compression > MPC
spase
hey i tested the encoder frank.. thought youd be interested (i used "higher" by creed, as i always do):

heres what the command prompt left:

new encoder
------------------
C:mpc>mppenc-new 1.wav 1.mpc -v -v -scale 0.98765 -ltq fil
MP+/MPC Encoder ? --ALPHA VERSION-- © 1999-2001 Buschmann/Klemm

encoding file "1.wav"
to file "1.mpc"

StreamVersion 7, Profile 'Standard'

fader: in 0.00 s, out 0.00 s.
scaling input by 0.98765
maximum bandwidth: 22050 Hz
MS: enhanced
Ltq: fil (offset: 0.0 dB)
TMN set to 18.00 dB
NMT set to 6.00 dB
exploitation of temporal post masking
no minimum SMR
no deleting of input file after encoding

%| frames| duration| remaining|avg.bitrate| speed| coding time
99.9 12128 05:16.813 -00:00:00 187 kbit 9.59x 00:33.057

old encoder
----------------
C:mpc>mppenc 1.wav 1-old.mpc -v -v -scale 0.98765 -ltq fil

MP+ v1.7.9c © 1999-2001 Andree Buschmann

encoding file "1.wav"
to file "1-old.mpc"

StreamVersion 7, Profile: "standard"

-> scaling input by 0.988
maximum bandwidth: 22050 Hz
MS: enhanced
Ltq: fil (offset: 0.0 dB)

%| frames| duration| remaining|avg.bitrate| speed| coding time
100.0 12129 05:16.839 -00:00:00 187 kbit 5.26x 01:00.307

possible problems with the new encoder:
- goes to 99.9% not 100% (display routine bug?)
- for some reason the file by this encoder is 7,398,840 bytes (7,398,912 bytes on disk) while from the old encoder it is 7,399,052 bytes (7,399,424 bytes). they both show the same average bitrate (186.8 kbit/s) and both show the same amount of frames encoded (12129) and the same duration (00:05:16 hms) maybe this is because there is no clipping prevention information?

as far as quality goes, it seems upon a casual listening test to be the same (when i say casual i mean i listened to the both in succession on my speakers) so thats good.

can others test this too?
lucpes
Yeah, same for me too... I guess the optimizations were for speed, not quality.

DumbAss question: why is the bitrate around 170 kbps for standard and around 200 kbps for xtreme... shouldn't it be more "jumpy" on difficult stuff?
john33
Tests on 0.90f & 0.90i as follows:
Enc v1ave Range v2ave Range
0.90f 5.39x 5.34-5.44 5.45x 5.32-5.56
0.90i 5.23x 5.04-5.44 5.48x 5.41-5.58
Speed averaged over a number of tracks of different types, the
same tracks for each.
PC - PIII-750 Coppermine, 256MB RAM, Windows-Me.

I tried mailing this to Frank but his mail server consistently refuses my email address as a vaild return address!!
Garf
QUOTE
Originally posted by lucpes
Yeah, same for me too... I guess the optimizations were for speed, not quality.

DumbAss question: why is the bitrate around 170 kbps for standard and around 200 kbps for xtreme... shouldn't it be more \"jumpy\" on difficult stuff?


a) it's hard to judge what may be difficult stuff for the codec

b) if a non-MP3 encoder is stable enough, the bitrate fluctuations it will generate are generally relatively small compared to MP3 (as far as I understand it, it's because of more flexible bit-allocation possibilities)

You can observe (b) clearly in MPC and Vorbis RC2.

If you are used to VBR MP3 you may be tempted to think they are using ABR, but they're not.

--
GCP
meff
works perfect for me, the audio sounds pristine. im using the linux version of the encoder, klemm's version with cdparanoia and GRIP to put it all together.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.