* Files with PNS are marked as SV 7.1 to prevent confusion with old decoders
* URL for download displayed on unknown StreamVersions
* Bug fixes in XMMS
* mppenc now needs less bitrate while at least maintaining the quality
* smart help screens for mppenc
* Changed overwrite behavior of mppenc
http://www.uni-jena.de/~pfk/MPP/ (http://www.uni-jena.de/~pfk/MPP/)
* Update: Improved 1.06 available *
Compiled Windows binaries for 16...32 bit decoders available here (http://www.saunalahti.fi/~cse/mppdec_1.04.zip).
There seems to be a weird little bug in the latest Winamp plug-ins, concerning filenames.
I noticed that if an MPC file doesn't have any tags, the plugin tries to fill in the fields by itself. It can 'guess' the album name/year, song artist/title and number from the foldername and filename.
Works pretty good, but today i played an album where the songs had these names:
01 Notorious B.I.G. - Notorious Thugs.mpc
02 Notorious B.I.G. - Miss U.mpc
03 Notorious B.I.G. - Another.mpc
...
The plugin failed in retrieving the tag info, displaying this playlist:
1. Mpc 2 - - Notorious Thugs
2. Mpc 2 - - Miss U
3. Mpc 2 - - Another
In the "Info" tab of Winamp, it was all mixed up, for instance: Track #: "03 Notorious B.I.G", Title: "- Another", Artist: "Mpc 2".
I reckon this is because of the extra dots in the filename... but what can i do, that's what the guy is (was) called.
Originally posted by CiTay
In the "Info" tab of Winamp, it was all mixed up, for instance: Track #: "03 Notorious B.I.G", Title: "- Another", Artist: "Mpc 2".
I reckon this is because of the extra dots in the filename... but what can i do, that's what the guy is (was) called.
Thanks for reporting, I had included one naming scheme in the middle of the old ones and that caused the problem. It should be fixed in this version (http://www.saunalahti.fi/~cse/in_mpc_0.94.zip).
Is it possible to directly convert older files into the new version to pick up the space savings?
Originally posted by Case
Thanks for reporting, I had included one naming scheme in the middle of the old ones and that caused the problem. It should be fixed in this version (http://www.saunalahti.fi/~cse/in_mpc_0.94.zip).
Ah yes, the bug is fixed. Thanks!
Chemical Brothers "Dig Your Own Hole" - Electronica, Trip-Hop:
mppenc 1.02 --xtreme (no tweaks): 86.0 MB; 190 kbps ave
mppenc 1.04 --xtreme (no tweaks): 74.8 MB; 164 kbps ave
What have you done, Frank, to reduce the encoded file sizes?
Great work.
Addendum:
Richard Thompson "Mock Tudor" - British Folk/Rock:
mppenc 1.02 --xtreme (no tweaks): 80.3 MB; 204 kbps ave
mppenc 1.04 --xtreme (no tweaks): 78.3 MB; 198 kbps ave
Apparently the aggressive bitrate savings are to be had in electronica, not folk/rock.
My mileage is a little less impressive, but I use a command-line with more overkill:
--insane --nmt 16 --tmn 32 --verbose --verbose
I encoded a live show that was an hour duration. With 1.02, the file size was 136MB; with 1.04 the file size is 134MB. It would appear then, that the new encoder makes more of a difference shaving the bitrate with less aggressive settings...
The sound quality is superb, as always. Case, the 24-bit decoder works fine, too. Many thanks.
Originally posted by Ruse
mppenc 1.02 --xtreme (no tweaks): 86.0 MB; 190 kbps ave
mppenc 1.04 --xtreme (no tweaks): 74.8 MB; 164 kbps ave
Now thats a significant reduction. These bitrates (164) more or less fall into the 'standard' category. Now if there's no difference in sound quality, thats a really good achievement. But is so ?
Or is Frank trying to prove that the 'standard' bitrates are indeed 'no different' than the 'xtreme' bitrates as far as quality is concerned ?
Anyone checked out the bitrate differences for 'standard' ?
http://www.hydrogenaudio.org/forums/showth...15496#post15496 (http://www.hydrogenaudio.org/forums/showthread.php?s=&postid=15496#post15496)
I think the developers liked Garf's suggestion.
Originally posted by rjamorim
http://www.hydrogenaudio.org/forums/showth...15496#post15496 (http://www.hydrogenaudio.org/forums/showthread.php?s=&postid=15496#post15496)
I think the developers liked Garf's suggestion.
Is that why the bitrate decreased?
Originally posted by macdaddy
Is that why the bitrate decreased?
I doubt. I was just kidding.
Originally posted by rjamorim
http://www.hydrogenaudio.org/forums/showth...15496#post15496 (http://www.hydrogenaudio.org/forums/showthread.php?s=&postid=15496#post15496)
I think the developers liked Garf's suggestion.
Not a bad idea of Garf's!
Trouble is in this instance, the --xtreme setting --verbose comments confirm that --xtreme is still nmt 8, tmn 20, and other parameters appear unchanged: so what has happened?
Originally posted by Ruse
Trouble is in this instance, the --xtreme setting --verbose comments confirm that --xtreme is still nmt 8, tmn 20, and other parameters appear unchanged: so what has happened?
Verbose was fux0red to give you the impression it's encoding with those parameters.
(kidding again...)
Originally posted by Ruse
Chemical Brothers "Dig Your Own Hole" - Electronica, Trip-Hop:
mppenc 1.02 --xtreme (no tweaks): 86.0 MB; 190 kbps ave
mppenc 1.04 --xtreme (no tweaks): 74.8 MB; 164 kbps ave
[...]
Apparently the aggressive bitrate savings are to be had in electronica, not folk/rock.
Bola "Fyuti" - IDM
mppenc 1.02 --xtreme: 85.4 MB; 205.8 kbps
mppenc 1.04 --xtreme: 81.2 MB; 196.3 kbps
Another electronic album... not quite as much of a savings either so the bit reduction here don't seem to quite be universal, but it's still not bad.
I haven't really had a chance to scrutinze the quality or encode much else though so I'll have to give that a shot and see how it works out.
> Anyone checked out the bitrate differences for 'standard' ?
A-ha 'Lifelines ' --standard
(just one track, how do I check the average bitrate for the whole album?)
1.02 - 171.7kbps, 5.28mb
1.04 - 158.3kbps, 4.86mb
Originally posted by Q!
(just one track, how do I check the average bitrate for the whole album?)
Download EncSpot (http://www.guerillasoft.com/EncSpot2/index.html): http://www.guerillasoft.com/EncSpot2/EncSp...Basic%202.0.zip (http://www.guerillasoft.com/EncSpot2/EncSpot%20Basic%202.0.zip)
It can not only do MP3 analyzing, but also basic MPC analyzing. It shows the average bitrate for a folder in the lower left corner of it's window.
Thanks!
A-ha 'Lifelines ' (--standard)
1.02 - 76.4MB, 173.0kbps
1.04 - 68.4MB, 154.7kbps
Originally posted by CiTay
Download EncSpot (http://www.guerillasoft.com/EncSpot2/index.html): http://www.guerillasoft.com/EncSpot2/EncSp...Basic%202.0.zip (http://www.guerillasoft.com/EncSpot2/EncSpot%20Basic%202.0.zip)
It can not only do MP3 analyzing, but also basic MPC analyzing. It shows the average bitrate for a folder in the lower left corner of it's window.
<<<Remark: The dialog boxes of # PHP List Quotes
are clean of helping information about what this
is>>>
In one of the packages there's list.exe
list.exe *
list.exe
PCM size File size Ratio kbps Duration Param Frequency Name
0.889 0.080 128 0:05.042 (2x16 44.1 kHz) 100only.mp3
2.362 1.254 1.882 750 0:13.390 (2x16 44.1 kHz) 11.pac
0.882 0.046 73.9 0:05.000 (2x16 44.1 kHz) 60.pac
1.031 0.659 1.566 901 0:05.849 (2x16 44.1 kHz) Bassdrum.pac
1.072 0.510 2.102 671 0:06.082 (2x16 44.1 kHz) BlackBird.pac
1.161 0.173 6.687 211 0:06.583 (2x16 44.1 kHz) Castanets-v00_209Kb.mp2
1.161 0.194 5.956 237 0:06.583 (2x16 44.1 kHz) Castanets-v05_235Kb.mp2
1.161 0.228 5.077 278 0:06.583 (2x16 44.1 kHz) Castanets-v10_276Kb.mp2
1.161 0.267 4.335 326 0:06.583 (2x16 44.1 kHz) Castanets-v15_323Kb.mp2
1.170 0.631 1.855 761 0:06.634 (2x16 44.1 kHz) Castanets.pac
1.161 0.159 7.292 194 0:06.583 (2x16 44.1 kHz) Castanets_192Kb.mp2
1.831 0.124 48.1 0:20.767 (2x16 22050 Hz) Classic_48Kb.mp3
1.748 0.138 56.1 0:19.827 (2x16 22050 Hz) Classic_56Kb.mp3
2.035 1.236 1.645 858 0:11.538 (2x16 44.1 kHz) Daughter (Pearl Jam).pac
5.460 3.110 1.756 804 0:30.953 (2x16 44.1 kHz) Fools.pac
10.934 0.744 96.1 1:01.989 (2x16 44.1 kHz) Funky_96Kb.mp3
1.063 0.274 3.880 364 0:06.030 (2x16 44.1 kHz) Granados.pac
1.051 0.473 2.220 636 0:05.958 (2x16 44.1 kHz) Hex.pac
0.658 0.084 7.823 131 0:05.148 (2x16 32 kHz) Hobbit-q1.mp3
0.658 0.086 7.583 135 0:05.148 (2x16 32 kHz) Hobbit-q2.mp3
0.655 0.361 1.813 565 0:05.120 (2x16 32 kHz) Hobbit.pac
1.060 0.689 1.538 918 0:06.013 (2x16 44.1 kHz) KMFDM-Dogma.pac
2.023 0.869 2.326 607 0:11.471 (2x16 44.1 kHz) QueenGoodOldFashioned.pac
2.479 0.224 128 0:14.054 (2x16 44.1 kHz) Raspberry_Beret_128Kb.mp3
1.239 0.449 2.756 256 0:14.054 ( 16 44.1 kHz) Raspberry_Beret_256Kb.mp3
1.916 0.130 96.3 0:10.867 (2x16 44.1 kHz) Spot1_96Kb.mp3
2.004 0.136 96.3 0:11.363 (2x16 44.1 kHz) Spot2_96Kb.mp3
2.059 0.140 96.3 0:11.677 (2x16 44.1 kHz) Spot3_96Kb.mp3
1.004 0.091 128 0:05.695 (2x16 44.1 kHz) Test_128Kb.mp2
2.424 1.872 1.295 1090 0:13.744 (2x16 44.1 kHz) Tristania-ruins-intro.ape
1.455 1.106 1.316 1073 0:08.252 (2x16 44.1 kHz) applaud.pac
5.234 0.712 7.344 192 0:29.675 (2x16 44.1 kHz) applaus.mp3
5.237 3.014 1.737 812 0:29.690 (2x16 44.1 kHz) applaus.pac
1.031 0.659 1.566 901 0:05.849 (2x16 44.1 kHz) bassdrum.pac
Error: 1002: invalid input file
2.813 1.490 1.888 748 0:15.950 (2x16 44.1 kHz) bi.pac
0.876 0.536 1.633 432 0:09.937 ( 16 44.1 kHz) cardigans.pac
3.305 1.333 2.479 569 0:18.739 (2x16 44.1 kHz) death2.pac
2.726 1.404 1.942 727 0:15.458 (2x16 44.1 kHz) dogies.pac
2.848 1.157 2.462 573 0:16.147 (2x16 44.1 kHz) dr4.pac
39.010 23.317 1.673 843 3:41.147 (2x16 44.1 kHz) drone.pac
10.584 5.665 1.868 755 1:00.002 (2x16 44.1 kHz) drone_short.pac
1.000 0.624 1.601 882 0:05.669 (2x16 44.1 kHz) else3.pac
0.882 0.458 1.922 734 0:05.000 (2x16 44.1 kHz) fatboy.pac
4.513 3.114 1.449 974 0:25.585 (2x16 44.1 kHz) ftb_samp.pac
2.990 0.271 128 0:16.953 (2x16 44.1 kHz) g_boink.mp3
7.064 0.961 7.345 192 0:40.046 (2x16 44.1 kHz) gitarre.mp3
7.066 1.625 4.346 325 0:40.060 (2x16 44.1 kHz) gitarre.pac
1.764 1.054 1.673 843 0:10.001 (2x16 44.1 kHz) goldc.pac
1.626 0.820 1.982 712 0:09.220 (2x16 44.1 kHz) gonna_fly_now.pac
0.986 0.385 2.563 551 0:05.593 (2x16 44.1 kHz) guitar.pac
0.446 0.177 2.511 562 0:02.531 (2x16 44.1 kHz) hihat.pac
1.834 0.827 2.216 637 0:10.398 (2x16 44.1 kHz) instruments.pac
6.171 3.782 1.631 865 0:34.984 (2x16 44.1 kHz) iron.pac
1.289 0.859 1.501 470 0:14.624 ( 16 44.1 kHz) jacob.pac
1.392 0.643 2.166 473 0:10.880 (2x16 32 kHz) jewharp.pac
0.745 0.404 1.844 555 0:05.824 (2x16 32 kHz) jo3.pac
0.751 0.069 94.1 0:05.868 (2x16 32 kHz) jo3q1.mp3
0.751 0.071 97.7 0:05.868 (2x16 32 kHz) jo3q2.mp3
1.870 0.915 2.043 691 0:10.606 (2x16 44.1 kHz) lalaw.pac
2.514 1.058 2.376 594 0:14.257 (2x16 44.1 kHz) left-dist.pac
0.883 0.643 1.374 1027 0:05.007 (2x16 44.1 kHz) liberate.pac
1.731 0.970 1.783 791 0:09.813 (2x16 44.1 kHz) main_theme.pac
2.455 1.442 1.702 414 0:27.837 ( 16 44.1 kHz) mixed.pac
1.866 0.775 2.406 587 0:10.580 (2x16 44.1 kHz) mouth_organ.pac
0.700 0.365 1.913 738 0:03.968 (2x16 44.1 kHz) mstest.pac
10.584 4.633 2.284 618 1:00.000 (2x16 44.1 kHz) music.pac
2.259 1.573 1.437 982 0:12.812 (2x16 44.1 kHz) oasis.pac
1.227 0.698 1.758 803 0:06.961 (2x16 44.1 kHz) ogpulse.pac
1.812 0.614 2.948 479 0:10.272 (2x16 44.1 kHz) piano.pac
2.648 1.347 1.965 718 0:15.013 (2x16 44.1 kHz) pipes.pac
1.400 0.970 1.443 978 0:07.939 (2x16 44.1 kHz) qrbic_see.pac
1.037 0.396 2.616 540 0:05.884 (2x16 44.1 kHz) short.pac
2.042 1.069 1.909 739 0:11.579 (2x16 44.1 kHz) si.pac
4.483 2.578 1.739 812 0:25.415 (2x16 44.1 kHz) spahm.pac
1.568 1.042 1.504 938 0:08.893 (2x16 44.1 kHz) st_jacob.pac
1.400 0.414 3.379 418 0:07.936 (2x16 44.1 kHz) t1.pac
2.539 0.713 3.561 396 0:14.395 (2x16 44.1 kHz) test.pac
2.178 0.948 2.296 615 0:12.352 (2x16 44.1 kHz) testsignal1.pac
0.714 0.337 2.117 667 0:04.048 (2x16 44.1 kHz) testsignal2.pac
0.026 0.009 2.718 260 0:00.300 ( 16 44.1 kHz) testsignal3.pac
0.790 0.360 2.191 644 0:04.480 (2x16 44.1 kHz) testsignal4.pac
1.355 0.940 1.442 979 0:07.687 (2x16 44.1 kHz) tpd.pac
1.917 1.201 1.597 442 0:21.745 ( 16 44.1 kHz) tr-left.pac
0.672 0.397 1.692 834 0:03.810 (2x16 44.1 kHz) track7.pac
1.478 0.573 2.579 547 0:08.379 (2x16 44.1 kHz) vangelis1.pac
0.823 0.472 1.744 809 0:04.670 (2x16 44.1 kHz) vbrtest.pac
2.095 1.397 1.499 941 0:11.879 (2x16 44.1 kHz) velvet.pac
3.707 2.179 1.701 830 0:21.016 (2x16 44.1 kHz) wait.pac
5.277 3.592 1.469 961 0:29.916 (2x16 44.1 kHz) youcantdothat.pac
237.993 106.635 2.232 598 23:45.724 ---Sum---
Yes, seems like this would also work. But what's that:
10.934 0.744 96.1 1:01.989 (2x16 44.1 kHz) Funky_96Kb.mp3
...
1.916 0.130 96.3 0:10.867 (2x16 44.1 kHz) Spot1_96Kb.mp3
2.004 0.136 96.3 0:11.363 (2x16 44.1 kHz) Spot2_96Kb.mp3
2.059 0.140 96.3 0:11.677 (2x16 44.1 kHz) Spot3_96Kb.mp3
Invalid MP3 framesizes... list.exe needs some accuracy tunings.
Is mppenc 1.04 based on one of the four versions of mppenc, that were posted recently?
Just for the record, I encoded two trance compilations (eye trance 3 and 4 without the turntablemix) at --standard --nmt 8.
v1.02: 414mb
v1.04: 383mb
That's a saving of 31mb or ~7.5%. If quality doesn't suffer, this is quite impressive imo.
I'm still a little sceptical though, but I guess I've been brainwashed to just compare bitrates without actually listening. Everything sounds ok to me, but then again, I'm not the one to ask these things.
Originally posted by CiTay
Yes, seems like this would also work. But what's that:
Invalid MP3 framesizes... list.exe needs some accuracy tunings.
This is the exact bitrate of the file.
Filesize * 8 bit/byte / playtime
The program shows the really needed bitrate.
A MP3 stream with 3 MByte ID3V2 tags can have
700...800 kbps (it is not difficult to find such
nonsense in the internet, 15 MP3 files with
96 kbps, Xing encoded + cover images, the same
images in every MP3 file)
No one ever answered the question asked before... What is the reason for the bitrate drops in --xtreme and --standard in the new version of the encoder?
Also, I'm confused by your analysis of this site, Frank. I've never had a single problem with this site, let alone be confused by it. But...to each their own. For the record, I'd much rather use this site than use a newsgroup.
Nick
The primary question raised again by NickSD was still not answered. :ponder:
I think this is deviating too much from the main topic. And the things behind he 'bitrate reduction' have not been addressed at all.
Appreciate if Frank (or someone else) could throw some light on whats behind this whole thingy of the significant birate reduction...
Or whether the MPC developers really felt what Garf said (and what I believe too) is correct and made the 1.04 versions
Cheers!
experttech.
Cleaned up the thread and moved the OT stuff here (http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=2010).
Having read two pages of this topic I've seen nothing explaining how this reduced bitrates came. Can someone explain it, please. To all of us who asked.
Thnx
for me mppenc version 1.02 sounds a little bit better than version 1.04 at the middle- and lower high- frequency section. tested on winxp using winamp and suse linux 8.0 using xmms.
does anyone now an gapless_playback plugin for xmms?
Dezibel
I made a few test with mppenc 1.04 and one of them is strange to me.
Album : Tina Turner - Simply The Best (best of)
Track : River Deep Mountain High ( it' a pretty old recording)
mppenc 1.01j --standard (no tweaks) --> 133 kbps
mmpenc 1.04 --standard (no tweaks) --> 85 kbps
mppenc 1.04 --xtreme (no tweaks) --> 95 kbps
As far as my hearing goes, the new (1.04) --standard and --xtreme ar as good as
the previous ones (1.01) and I 'm aware that this is an old recording with limited bandwith
but the sudden drop in bitrate really makes me wonder...
So what has really changed from 1.01 to 1.04 ?
This bitrate drops in the 20% range make me kind of nervous...
Can we still trust MPC to be as transparent as it was or will there be artifacts surfacing here or there? Do we have to start extensive listening tests now ?
Pleazz some comments from MPC development people on this.
Originally posted by Case
* Files with PNS are marked as SV 7.1 to prevent confusion with old decoders
* URL for download displayed on unknown StreamVersions
* Bug fixes in XMMS
* mppenc now needs less bitrate while at least maintaining the quality
* smart help screens for mppenc
* Changed overwrite behavior of mppenc
http://www.uni-jena.de/~pfk/mpp/ (http://www.uni-jena.de/~pfk/mpp/)
I believe Frank when he says it will at least remain the same quality or be even better, but I also would some kind of explination for this.
I'm just curious how he did it .
@Hanky : I wouldn't bring out the headphones and tests just yet, don't panic mp+ and mpc has always been around quality and I don't think Frank or the other developers would sacrifice on that.
I do seem to recall that one of the features of StreamVersion 8 was the reduction of bitrates via better Huffman coding. So IMHO Frank might be using this as a method of beta testing the method out.
Correct me if I am wrong I did a search for streamversion and huffman but came out empty. I am not to sure but offering an opinion for whats its worth
Cheers
AgentMil
Originally posted by AgentMil
I do seem to recall that one of the features of StreamVersion 8 was the reduction of bitrates via better Huffman coding. So IMHO Frank might be using this as a method of beta testing the method out.
Correct me if I am wrong I did a search for streamversion and huffman but came out empty. I am not to sure but offering an opinion for whats its worth
Cheers
AgentMil
This don't plays a big role for normal encodings.
I expect not more than 1...3% .
Enhanced huffman coding will play a role on tracks like fatboy and
castagnets and very high bitrate encodings where MPC now have some very
silly code.
May be a SV 7.2 which breaks compatibiltity will show most of the effects.
Or is Intensity Stereo for <100 kbps more important?
most ppl here will care less about low bitrates and would like high bitrate/quality (not that it needs much improvement but a few bits cut of here and there will not hurt anybody) to be improved before anything else.
Unfortunately, I am relying completely on subjective perception but it seems to me that mppenc 1.04 doesn't quite sound as good as 1.02 in the higher frequencies. There seems to be an "edge" to some of the high frequency transients that I don't remember hearing before. Hard to describe and harder to prove.
Originally posted by mithrandir
Unfortunately, I am relying completely on subjective perception but it seems to me that mppenc 1.04 doesn't quite sound as good as 1.02 in the higher frequencies. There seems to be an "edge" to some of the high frequency transients that I don't remember hearing before. Hard to describe and harder to prove.
Hrmm.. do you actually have a desire to prove this?
Just curious, cause it almost sounds like you don't want to try or something. If you can't prove it though, then wouldn't you be inclined to believe it was only a placebo effect? So then why would it be worth mentioning ahead of time?
Sorry, I just don't quite get what you are trying to do here If you think there's a difference then it's time to fire up the abx!
For what it's worth, I'm not saying there isn't a difference, I haven't had time to really listen for myself.. I'd just like to see a constructive examination if there is going to be one, rather than just speculation. I'm tired of seeing other people jump to conclusions about something based on what may be pure speculation.. it happens all the time with MP3 and the --alt-presets (remember the joint stereo stuff?)....
Originally posted by Dibrom
For what it's worth, I'm not saying there isn't a difference, I haven't had time to really listen for myself.. I'd just like to see a constructive examination if there is going to be one, rather than just speculation. I'm tired of seeing other people jump to conclusions about something based on what may be pure speculation.. it happens all the time with MP3 and the --alt-presets (remember the joint stereo stuff?)....
Agreed, but the fact that Frank already made several posts in this thread, but still did not give any explanation about the bitrate decreases doesn't help it much. It almost seems as if he is hiding something.
Honestly, until I see some explanation, I'm a bit afraid to use this version on my music. I thought MPC was already heavily tuned, so I'm really surprised to see the big bitrate drops mentioned in this thread. It's almost too good to be true.
It almost seems as if he is hiding something.
come on!!!
that's just insane. Just because Frank doesn't have the time to explain every little technical detain.
I say I would rather have him programming his great encoder instead of having to answer what he did to cut of 1%-3%.
MPC is great and Frank has only made it better.
I tried to compare 1.02 and 1.04 (on recently encoded CD ). Profiles ware : standard (2CD), extreme, braindead, and insane 16-32. Disc : only classical music (concerto and symphonic music only)
The difference is « only » 4-6 kb/s (never less, never more) between 1.02 and 1.04. On twekaed profil (--insane --nmt16 --tmn 32 : 318 kb/s on a Mahler Symphony disc with 1.02, 312 or 313 with 1.04) or naked profile. Every track on the same CD are affected, and the bitrate drop is the same.
I don't care with this new version. Thanks to Frank Klemm (what happen with mppenc 1.03 ?)
Thanks Frank for clearing what I thought was the real reason for the bitrate drops.
Well so far encoding with 1.04 and then comparing 1.02 I seriously do not hear a difference. As you can gather from my signature that is the command line I use.
If there was a difference wouldn't that difference be heard *clearly* on those 1% of clips that MPC is supposedly has problems encoding?
Just my 0.02c but I seriously do not believe that there is no difference between 1.02 and 1.04, unless someone can come up with a clip that clearly shows the problem.
On another point, isn't it the goal of lossy audio compressors to achieve the highest possible quality at the lowest possible bitrate and not the other way around (high bitrate and high quality)?
Thanks Frank for the continued updates on MusePack!!
Cheers
AgentMil
Originally posted by Jan S.
I say I would rather have him programming his great encoder instead of having to answer what he did to cut of 1%-3%.
Originally posted by cmagic
Album : Tina Turner - Simply The Best (best of)
Track : River Deep Mountain High ( it' a pretty old recording)
mppenc 1.01j --standard (no tweaks) --> 133 kbps
mmpenc 1.04 --standard (no tweaks) --> 85 kbps
mppenc 1.04 --xtreme (no tweaks) --> 95 kbps
correct my if I'm wrong, but this seems to be a reduction by more than just 1%-3%...
Frank, care to elaborate please?
Originally posted by Dibrom
Hrmm.. do you actually have a desire to prove this?
Just curious, cause it almost sounds like you don't want to try or something. If you can't prove it though, then wouldn't you be inclined to believe it was only a placebo effect? So then why would it be worth mentioning ahead of time?
I've been using mppenc since version 0.90, but 1.04 is the first encoder that made something in my head say "hmm, something's different with the output". I wasn't necessarily expecting to hear any changes but the fact that some flag in my head got raised after listening to the output I have to wonder if 1.02 and 1.04 produce perceptually identical output. Could it be a placebo effect? Of course it could but I don't know at this point.
It's not a simple issue because I was using --standard when I think I heard something different. When I was playing with --braindead, 1.02 and 1.04 sound identical. Since the presets have been modified slightly (in some cases, largely) is it appropriate to ABX the same preset across encoder versions? For instance, --standard has now uses --nmt 6.5 instead of --nmt 6, which is a theoretical improvement. --thumb has been "overhauled". If 1.04 --thumb sounds different than 1.02 --thumb on an ABX test (and my guess is that it does), we still don't know if the difference equates to an improvement. It could be a degradation...all an ABX test tells us is that they are different (or not different).
If I seem tentative, it's because I don't know where I want to take this. Run some ABX tests? If so, what are the appropriate conditions?
What I'm wondering is, if there wasn't any reduction of bitrates would anyone be doing those listening "tests"??
I personally always upgrade my encoder to the newest one and encode all my albums further with that with the same profile I always use.
I never really listen for differences as I always expect that it will be the same quality or better.
But I recently also encoded some albums with the new 1.04 and I'm getting a bit worried when I saw those bitrate reductions and some experiences of other users over here.
After (quite theoretical, i admit) inverse-mix-pasting tests of 1.04 against 1.0 in Cool Edit (using --standard and --braindead --nmt 15 --tmn 30), the only conclusion is that 1.0 is a wee bit better in the highs, but otherwise rather close to what 1.04 spits out.
Attempts to sound those differences out, on various ordinary songs encoded with --standard, were unsuccessful. Tonight i will try to do an ABX test with more challenging samples, but i'm not expecting big disappointments there either.
Originally posted by -=Ducky=-
What I'm wondering is, if there wasn't any reduction of bitrates would anyone be doing those listening "tests"??
I personally always upgrade my encoder to the newest one and encode all my albums further with that with the same profile I always use.
I never really listen for differences as I always expect that it will be the same quality or better.
But I recently also encoded some albums with the new 1.04 and I'm getting a bit worried when I saw those bitrate reductions and some experiences of other users over here.
I wouldn't really be worried at this point. Nobody has actually said that they "can" hear a difference for sure. So far, all I'm seeing is speculation. And the bit about inverse mixing is really useless as far as quality indication goes. The best encoder possible would sound flawless but would look horrible in a spectrogram... so you can't really tell anything from those unless you listen beforehand.
Until I actually see some abx results, I'm not going to assume either way... it's just not worth jumping to conclusions.
Originally posted by Dibrom
I wouldn't really be worried at this point. Nobody has actually said that they "can" hear a difference for sure. So far, all I'm seeing is speculation. And the bit about inverse mixing is really useless as far as quality indication goes. The best encoder possible would sound flawless but would look horrible in a spectrogram... so you can't really tell anything from those unless you listen beforehand.
I didn't want to draw conclusions about the sound quality, i wanted to see what could've changed to reduce the bitrate. I was reluctant to post the Cool Edit bit, because i thought i'd get jumped on for doing that... but hey... if i would've noted something more obvious in there, i maybe could've chosen some samples to exhibit a weak spot in 1.04. That's not the case.
The only thing left to do is to ABX. This i'll do tonight.
Originally posted by cmagic
I made a few test with mppenc 1.04 and one of them is strange to me.
Album : Tina Turner - Simply The Best (best of)
Track : River Deep Mountain High ( it' a pretty old recording)
mppenc 1.01j --standard (no tweaks) --> 133 kbps
mmpenc 1.04 --standard (no tweaks) --> 85 kbps
mppenc 1.04 --xtreme (no tweaks) --> 95 kbps
As far as my hearing goes, the new (1.04) --standard and --xtreme ar as good as
the previous ones (1.01) and I 'm aware that this is an old recording with limited bandwith
but the sudden drop in bitrate really makes me wonder...
So what has really changed from 1.01 to 1.04 ?
Reducing bitrate from 133 kbps to 85 kbps should be audible, isn't it?
Try to find out what happened. Be a detective!
Originally posted by Frank Klemm
Reducing bitrate from 133 kbps to 85 kbps should be audible, isn't it?
Try to find out what happened. Be a detective!
Yes, I guess it should but I was not able to tell the difference between the 133 kbps
1.02 encoded and the 85 kbps 1.04 encoded. (both with --standard)
Maybe my 45 years old hearing !
From about 20 albums I encoded with 1.04 it's the only track for which I found
such a dramatic bitrate drop. The average drop for the rest is 5 - 20 kbps with
bitrates never falling below 130.
This particular track is an old and quite bad recording with a huge lack of treble
could it be the reason ?
Also I think It's probably a mono recording, the CD booklet says the track
has been re-mastered and equalized.
I made new encodings and got :
135 kbps with mppenc 1.01j (straight --standard)
84.6 kbps with mppenc 1.04 (straight --standard)
Frank, I'll try to make the clip available somewhere so that you can check it out.
Sherlock
ABX test, equipment: Hercules GTXP, AKG K-290 headphones, PCABX 1.7.5 (BTW it looks awful with Windows XP's "Luna" GUI, somebody should fix that).
I used the "--radio" profile for all tests, to get usable results (--standard is already too good sometimes).
Sample: "SmashingSample89.wav"
mppenc 1.0, 139.8 kbps: 15/16. Cymbal in the right channel is overemphasized.
mppenc 1.04, 138.4 kbps: 14/16. Same effect, slightly less distinct. I would even say that this sounds a bit better than 1.0.
Sample: "dogwhistle.wav"
mppenc 1.0, 129.7 kbps: 16/16. The whistle tone appears to be lower. Nervous chirping of the noise.
mppenc 1.04, 123.4 kbps: 16/16. Same effect. Again it sounds a little more pleasant to my ears.
I can't test longer in a row. Odd results, the opposite of what i expected. Of course these are only two samples, and the bitrate difference isn't immense. But so far i couldn't ask for more than maintaining the quality level of 1.0, and this seems to have worked.
GCC 3.1 cannot compile the XMMS plugin correctly at an optimization level higher than -O1 (makes everything sound like udial)
GCC 2.95.3 works fine
--
GCP
Originally posted by Garf
GCC 3.1 cannot compile the XMMS plugin correctly at an optimization level higher than -O1 (makes everything sound like udial)
GCC 2.95.3 works fine
--
GCP
Test mppdec. Also publish config.h
--
Frank Klemm
Originally posted by CiTay
ABX test, equipment: Hercules GTXP, AKG K-290 headphones, PCABX 1.7.5 (BTW it looks awful with Windows XP's "Luna" GUI, somebody should fix that).
I used the "--radio" profile for all tests, to get usable results (--standard is already too good sometimes).
Sample: "SmashingSample89.wav"
mppenc 1.0, 139.8 kbps: 15/16. Cymbal in the right channel is overemphasized.
mppenc 1.04, 138.4 kbps: 14/16. Same effect, slightly less distinct. I would even say that this sounds a bit better than 1.0.
Sample: "dogwhistle.wav"
mppenc 1.0, 129.7 kbps: 16/16. The whistle tone appears to be lower. Nervous chirping of the noise.
mppenc 1.04, 123.4 kbps: 16/16. Same effect. Again it sounds a little more pleasant to my ears.
I can't test longer in a row. Odd results, the opposite of what i expected. Of course these are only two samples, and the bitrate difference isn't immense. But so far i couldn't ask for more than maintaining the quality level of 1.0, and this seems to have worked.
Most of the bitrate savings are not active in --radio. It is the mode with the smallest
changes.
Originally posted by Frank Klemm
Test mppdec. Also publish config.h
mppdec works. I didn't change config.h for the xmms plugin (I did for mppdec)
--
GCP
Originally posted by Garf
mppdec works. I didn't change config.h for the xmms plugin (I did for mppdec)
--
GCP
Publish config.h .
Do what I say. Don't thought about it.
mppdec tests all dirty tricks it uses, WinAMP not.
The XMMS plugin 0.94 seems to be an empty archive, I get a 0 byte file, can anyone confirm this?
Also just wondering if the xmms plugin will support APE tags?
Originally posted by jeffster
The XMMS plugin 0.94 seems to be an empty archive, I get a 0 byte file, can anyone confirm this?
Works fine here.
Maybe your problem is that it's in bzip2 (bz2) format. Try right-clicking -> Save link as...
BTW: The file size, here, is 99Kb.
Regards;
Roberto.
Originally posted by rjamorim
Works fine here.
Maybe your problem is that it's in bzip2 (bz2) format. Try right-clicking -> Save link as...
Hi Roberto,
Nope that's not it, sorry I was actually referring to the binary at the bottom of the page (which is a zip file) not the source, but... if you can point out the steps required to compile it in linux I will give that a try.
Thanks,
Jeff
Originally posted by jeffster
Hi Roberto,
Nope that's not it, sorry I was actually referring to the binary at the bottom of the page (which is a zip file) not the source, but... if you can point out the steps required to compile it in linux I will give that a try.
Thanks,
Jeff
I have permanent Quota problems. I hope the situation becomes
better when I completely outsource the WinAMP plugin development
to Case from Finnland. Thank You for your engagement!
I don't have any hopes that the "offical" cites are usable for
me until 2010 for that purpose.
Also some webspace for listening examples were nice. Currently
I removed most of the stuff from my website.
<Informational> I'm currently NOT in Jena, this is written outside
my home town, emails are not answered.
<Informational> This is written from a public web terminal and
I have the same problems with hydrogenaudio I told about.
Originally posted by jeffster
if you can point out the steps required to compile it in linux I will give that a try.
Just download, tar -jxvf, make (no ./configure or anything), and then copy it to your xmms Input dir (mine's /usr/lib/xmms/Input), and it should work.
Originally posted by Dibrom
Just download, tar -jxvf, make (no ./configure or anything), and then copy it to your xmms Input dir (mine's /usr/lib/xmms/Input), and it should work.
Thanks, it worked!
Originally posted by Frank Klemm
I have permanent Quota problems. I hope the situation becomes
better when I completely outsource the WinAMP plugin development
to Case from Finnland. Thank You for your engagement!
I don't have any hopes that the "offical" cites are usable for
me until 2010 for that purpose.
Also some webspace for listening examples were nice. Currently
I removed most of the stuff from my website.
You might try SourceForge (sourceforge.net). Back when I registered the rule was that they require the projects they host to be free, opensource or advance free software in some way.
You could say that mpc decoders are open source, and testclips help LAME and Vorbis as well.
If your project gets accepted, you get 100Mb of http space on a pretty
fast connection for free.
(their service/support sucks, but you can't beat the price...)
--
GCP
The file I changed was mpp.h, not config.h. There is no equivalent in the xmms plugin.
config.h contents:
/* Determine Endianess of the machine */
#define HAVE_LITTLE_ENDIAN 1234
#define HAVE_BIG_ENDIAN 4321
#define ENDIAN HAVE_LITTLE_ENDIAN
/* Test the fast float-to-int rounding trick works */
#define HAVE_IEEE754_FLOAT
#define HAVE_IEEE754_DOUBLE
/* Test the presence of a 80 bit floating point type for writing AIFF headers */
#define HAVE_IEEE854_LONGDOUBLE
In mpp.h I just enabled:
#define MAKE_16BIT
--
GCP
This is getting crazy.
Aside from its phenomenal quality, one of the main things that attracted me to MPC was its inherent simplicity: a handful of profiles to accomplish all my encoding needs. Now it seems to be going the way of LAME: an endless, daily pursuit of some nebulous, subjective, "best" version and/or tweak.
Basically, I do three types of MPC encodings:
1. EAC rips, for which I use --xtreme (as is)
2. Mp3 transcodes, for which I use --standard (as is)
3. Very occasional cassette line-in recordings, for which I use --xtreme --nmt10
I have settled on the release version 1.0 of SV7, the 1.04 version of mppdec, the 0.84 version of ReplayGain, and Tag as my system of choice, and hereby withdraw from the ratrace in order to enjoy the music more.
May sound crazy, but it works for me, especially since cutting-edge info appears to be headed in a more esoteric direction, and there is no way I would be invited onto Frank's mailing list.
Regards,
Madrigal
Originally posted by Madrigal
I have settled on the release version 1.0 of SV7, the 1.04 version of mppdec, the 0.84 version of ReplayGain, and Tag as my system of choice, and hereby withdraw from the ratrace in order to enjoy the music more.
May sound crazy, but it works for me, especially since cutting-edge info appears to be headed in a more esoteric direction, and there is no way I would be invited onto Frank's mailing list.
I suggest you give mppenc 1.01j a try (more here (http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=2174)).
Also, i will post all relevant information from the list in the MPC section here. You won't miss anything important.
Originally posted by CiTay
I suggest you give mppenc 1.01j a try (more here (http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=2174)).
Also, i will post all relevant information from the list in the MPC section here. You won't miss anything important.
CiTay:
Thank you. I had noticed the many references to 1.01j (especially in comparison to 1.04), and will definitely give it a try, then choose between it and release version 1.0.
I am not retiring from keeping abreast of developments in the unfolding MPC story, only from the constant "update and compare" rut into which I had fallen.
Many thanks for your kind reply.
Regards,
Madrigal
IMHO MusePack Encoder v1.04, provides the same quality as the v1.01j version. I have done some very rudimentary listening test (ie. Encoding two differenct tracks and sitting down and listening, to them but not trying to pick out "flaws" but to see whether they both sound alike, which they both do). I know its not a "scientific" method of testing, but its all I got time for.
It would be great to find someone that has a clip that fails on v1.04 and passes on v1.01j.
*EDIT* Page two of this thread has some test done by CiTay. *EDIT*
Just my .02c
Cheers
AgentMil