Since Mp3 is a format and Lame is a codec, could Mp3 at 64- 96 Kbps ever sounds better aresounds closer to MP3 Pro... in other word better quality!! ( or has it reach its limit?? )
Or should i use Ogg instead. But ogg uses more CPU resouces than MP3 which is the only concern. Or thinking another way would ogg improve and have lower CPU resources as MP3??
Since Mp3 is a format and Lame is a codec, could Mp3 at 64- 96 Kbps ever sounds better aresounds closer to MP3 Pro... in other word better quality!! ( or has it reach its limit?? )
Or should i use Ogg instead. But ogg uses more CPU resouces than MP3 which is the only concern. Or thinking another way would ogg improve and have lower CPU resources as MP3??
AFAIK, if it didn't reach its limits, it's almost there, but really, i don't know for sure.
Anyway, I'll recommend you to go for Ogg Vorbis. Have you tried the Tremor integer decoder? I think it's less computational intensive.
Have you tried the Tremor integer decoder? I think it's less computational intensive.
It isn't on any machine with a good FPU. Only for K6, Cyrix, 486 and so, not for Pentiums/Athlon.
Or should i use Ogg instead. But ogg uses more CPU resouces than MP3 which is the only concern. Or thinking another way would ogg improve and have lower CPU resources as MP3??
Just wondering why should cpu resources be that much of a concern? More than 95% of PCs out there should be more than powerful enough to decode Ogg Vorbis. Higher overhead is the natural price to pay for a more advanced encoder.
I'm afraid that by design, it is next to impossible for Ogg Vorbis to take up less resources. 1024-point iMDCT will always be more computationally intensive than 32x 18-point iMDCT + reconstructing from 32 subbands.
That is because i am trying to find a high quality low birtae codec to use with my video encoding. Since The video has to play on a specific spec of computer. i need the audio part to take the less resources as possible.
Any ideas?? How does AAC do comprae to ogg interms of decoding resources and quality??
i need the audio part to take the less resources as possible. Any ideas?? How does AAC do comprae to ogg interms of decoding resources and quality??
Resource.... use MP2. Maybe if there is an MPC DS filter...
AAC does the same 1024-point MDCT, so will be on the same order as Ogg.
MPC..... Does MPC in low bitrate ( 64 ) sound similar to MP3 ( 64 )??
MPC..... Does MPC in low bitrate ( 64 ) sound similar to MP3 ( 64 )??
With PNS it sounds much better.
So you are saying MPC with PNS @ 64 it sounds better tha MP3 Lame @ 64.
So isn't MPC with PNS @ 64 sounds close to ogg?? or is it still way off??
What is PNS anyway??
MPC..... Does MPC in low bitrate ( 64 ) sound similar to MP3 ( 64 )??
With PNS it sounds much better.
That's interesting... Do you perhaps know if Frank Klemm has the same opinion? Did you maybe compare it with mp3PRO, AAC or WMA9 at 64 kbps? Which MPC version would I have to download to test this for myself? And play it back with which Winamp plugin version?
So you are saying MPC with PNS @ 64 it sounds better tha MP3 Lame @ 64.
Yes.
So isn't MPC with PNS @ 64 sounds close to ogg?? or is it still way off??
I made some comparisons during ff123's last test and it depends quite a bit from sample. On difficult samples MPC allocates more bits than Vorbis and lowering this alters quality too much, but with --thumb profile it wasn't much worse (I rated it better on some files, worse on some).
What is PNS anyway??
Some info here (http://www.audiocoding.com/wiki/index.php?page=PNS).
That's interesting... Do you perhaps know if Frank Klemm has the same opinion?
I don't know this, but Klemm has said that he's not happy with it's quality yet as it's untuned.
Did you maybe compare it with mp3PRO, AAC or WMA9 at 64 kbps?
I did some tests during ff123's 64kbps test, see above. I didn't test all the samples, just few plus my own music and MPC did suprisingly well. Too bad I didn't store my results but I remember rating MPC highest on some of my tests. Note that going under profile --thumb degrades quality way too much, if --thumb uses too high bitrate then tweaking settings will make MPC lose.
Which MPC version would I have to download to test this for myself? And play it back with which Winamp plugin version?
I don't think PNS quality has been improved in recent updates, but it's best to use latest encoder anyway
I recommend decoding either with mppdec 1.93j or with this plugin (http://www.saunalahti.fi/cse/mpc/bin/in_mpc.exe).
I didn't test all the samples, just few plus my own music and MPC did suprisingly well. Too bad I didn't store my results but I remember rating MPC highest on some of my tests. Note that going under profile --thumb degrades quality way too much, if --thumb uses too high bitrate then tweaking settings will make MPC lose.
OK, and this preset averages at which bitrate normally, 70-90 kbps like -radio from PsyTEL AACEnc?
[later...]
Apparently these two presets come out quite the same in file size, I just noticed an average bitrate of ~75 kbps with --thumb while encoding the c't reference.wav. Is PNS enabled by default in this profile or do I have to add something on the command line?
I don't think PNS quality has been improved in recent updates, but it's best to use latest encoder anyway
I recommend decoding either with mppdec 1.93j or with this plugin (http://www.saunalahti.fi/cse/mpc/bin/in_mpc.exe).
I will have a look at it. Do you also offer the latest encoder version compiled for Windows on your site, or is it only available at Frank's website?
[later...]
The combination mppenc v1.93j / in_mpc.dll from your website does not work. The Winamp plugin complains about an "unknown stream version 7.15." Now what?
OK, and this preset averages at which bitrate normally, 70-90 kbps like -radio from PsyTEL AACEnc?
I have seen bitrates ~20 - ~90, usually it's around 70.
The combination mppenc v1.93j / in_mpc.dll from your website does not work. The Winamp plugin complains about an unknown stream version 7.15. Now what?
Mppenc 1.93j is pre-SV8 encoder, meant only for testing as bitstream isn't stable yet. Use mppenc 1.14.
The combination mppenc v1.93j / in_mpc.dll from your website does not work. The Winamp plugin complains about an unknown stream version 7.15. Now what?
Mppenc 1.93j is pre-SV8 encoder, meant only for testing as bitstream isn't stable yet. Use mppenc 1.14.
OK, who brought up this rumour that MPC isn't good enough at low bitrates, the Vorbis mafia?
I only had time for a short check today with the --thumb preset and the c't reference.wav, but you were right: it is in fact much better than MP3. It also can compete with the best codecs at 64 kbps, but one has to keep in mind that it uses about 20% more bits for that (76.4 kbps with mppenc 1.14). Nevertheless this is a very surprising result for me, but like I wrote before: don't trust anyone, even yourself... It would be interesting how it would sound at modem bitrates like 48 or 56 kbps, maybe with SBR on top of it.
And now....... mpc is going to rule the world.... again...... B)
Was anything planned in SV8 to improve in lowbitrate??
OK, who brought up this rumour that MPC isn't good enough at low bitrates, the Vorbis mafia?
No, harpsichord lovers
I really like this instrument, and noticed that harpsichord blows the bitrate up with musepack. At low setting, bitrate is really high, and quality significantly low. Curiously, the same encoding with --alt-preset are normal (but quality bad :-/ )
mpc 1.14 --quality 5 = 226 kb/s [standard]
mpc 1.14 --quality 4 = 182 kb/s [radio]
mpc 1.14 --quality 3 = 134 kb/s [thumb]
mpc 1.14 --quality 2 = 94 kb/s [telephone]
mpc 1.14 --quality 1.99 = 63 kb/s [below telephone]
lame 3.90.2 --alt-preset standard = 187 kb/s
lame 3.90.2 --alt-preset extreme = 223 kb/s
Lame VBR extreme is smaller than mpc --standard !
The track is from J.S. Bach,
Fugue BWV 892 in B major, 1994, recorded by Pierre Hantaï. All harpsichord tracks are turning round the same bitrate. This is a common situation for harpsichord recordings.
In comparison, the ogg table for the same track :
ogg vorbis 1.0 -q-1 = 49 kb/s [+ 9%]
ogg vorbis 1.0 -q 0 = 64 kb/s [0%]
ogg vorbis 1.0 -q 1 = 79 kb/s [-1%]
ogg vorbis 1.0 -q 2 = 99 kb/s [+ 3%]
ogg vorbis 1.0 -q 3 = 135 kb/s [+ 20%]
ogg vorbis 1.0 -q 4 = 163 kb/s [+ 27%]
ogg vorbis 1.0 -q 5 = 204 kb/s [+ 27%]
ogg vorbis 1.0 -q 6 = 237 kb/s [+ 23%]
Vorbis and mpc have the same reaction : bitrate explosion. LAME sucks. --alt-preset standard sound really bad (at least on the first notes, pure and sharp harpsichord), and I'm able to abx preset-extreme & preset-insane too (but quality is OK). It seems that psycho-accoustic model of mp3 (or just lame) is incomplete, buggy, or prehistoric (don't know).
At low bitrate now, mpc gives the most awfull sound of all encoding. I can't describe the 64 kb/s mpc file, even in french . Telephone is awfull too, vaguely the same than --alt-preset 64 [lame 3.93.1 test version] - with more chirps for mpc, much larger (+50%). Sound is muffled in the two cases.
Vorbis, in comparison, is fantastic. No care about snowy sound in that situation : distorsion is high (higher than mp3 encoding at 64 the same bitrate), but the harpsichord sound sharper, 'clearer' (much treble).
Acceptable sound is reached by ogg -q 3 [135 kb/s] and --radio profile for mpc [195 kb/s].
==> modem encoding are not conceivable with mpc for some music. If --radio profile gives a really good quality (at least for me), the quality drop under this profile begin to be worrying. The small comparison I did in the past between different codecs never surprised me and went (for once ) in the same way than common opinion. And I often find mp3 to be a more reasonnable choice than mpc (muffled sound, but low distorsion level). SBR may be helpful, but I'm not sure that time should be spend for tweaking mpc at such bitrate.
Has Dibrom or someone else a real explication (not supposition) for the unability of lame to properly encode harpsichord, by underrating the bitrate necessities ? Is this a bug, or an inevitable flaw for mp3 format ?
i don't see a whole lot of point in tweaking low-bitrate mpc either. ogg is available for lower-bitrate stuff, and aac+sbr will soon challenge there as well (or maybe even without sbr, in the new nero codec).
About harspichord:
Sorry, it's just a supposition, but could you try with gpsycho? (lame -V1 -h -mj)
I compared --alt-preset standard (3.90.2 - 187 kb/s) with lame -V1 -h -mj (3.93.1 160 kb/s).
=> the small lame command line is worse than --aps. Bitrate difference is really high, too, and can explain this obvious degradation (much higher distorsions). In comparison, --aps sound perfect
How can I increase bitrate without leaving gpsycho ?
I can send by mail the test sample (9 seconds, < 800 kb in .ape format)
You can increase bitrate by adding -V0 or --athlower xxx (x something like 4 or 5).
You can increase bitrate by adding -V0 or --athlower xxx (x something like 4 or 5) after --preset std. (although dibrom will probably warn you not to use such things.
Sorry for being stupid, but what should I type exactly :
--alt-preset standard -V0 -h -mj [span style='font-size:11pt;line-height:100%']
or[/span] -V0 -h -mj ?
By comparing --aps to -V0 -h -mj, the difference is in favor with aps (bitrate, by encoding the 10 first seconds : aps=184kb/s // -V -h -mj=178 kb/s). The small difference in size can't justify the real difference in quality.
Sorry, I edited my above post. You should understand better now.
But I think that you can stop trying. I was thinking that perhaps it could be a case where peak method for tonality detecting used by nspsytune could fail, but it seems that it's not the case.
i don't see a whole lot of point in tweaking low-bitrate mpc either. ogg is available for lower-bitrate stuff, and aac+sbr will soon challenge there as well (or maybe even without sbr, in the new nero codec).
As said earlier... MPC uses a lot less CPU resources than AAC and OGG.
As said earlier... MPC uses a lot less CPU resources than AAC and OGG.
But if you add SBR decoding, the CPU resources will explode (I suppose so...).
And seriously, who complained about ogg decoding ? Prehistoric PC users, with a 4 MB RAM Linux installation ?
OK, who brought up this rumour that MPC isn't good enough at low bitrates, the Vorbis mafia?
No, harpsichord lovers
Who? You can probably guess what I think of generalizing results from one sample with a very specific sound to comments like "MPC is no good at low bitrates, use OGG..." and so on.
I really like this instrument, and noticed that harpsichord blows the bitrate up with musepack.
That's OK, but it is no wonder that single high-pitched notes with a sharp attack and a rich harmonic spectrum can be "codec killers", especially at low bitrates. That's the reason I always use the c't reference.wav as a first test, although it's not perfect, but it gives a good "average" impression quickly.
At low setting, bitrate is really high, and quality significantly low. Curiously, the same encoding with --alt-preset are normal (but quality bad :-/ )
I skipped the most part of your posting, because you were describing some high bitrate settings like lame aps which are not in question in this thread. By the way, MPC really seems to be the format with the smallest CPU load, so I would recommend it to iwod alone for this reason, if he can integrate it into his video files.
==> modem encoding are not conceivable with mpc for some music. If --radio profile gives a really good quality (at least for me), the quality drop under this profile begin to be worrying.
I have a totally different impression of MPC --thumb and rather think it behaves almost identically compared to PsyTEL's -radio preset in terms of bitrate usage, but sounds better on all samples I've listened to so far, more naturally, less artifacts - even if I resample -radio to 32 kHz.
Taking into account that I rated this sound on a par with mp3PRO at 64 kbps CBR and ranking that as third best in the c't test, I would have a new alternative for my online demo tapes, if the bitrate would not jump up to 94 kbps with --thumb on one of my own recordings (92 kbps with PsyTEL -radio). To be fair, I should mention that I can't compare it to mp3PRO at 96 kbps VBR, because I only have the test encoder from Coding Technologies with a fixed CBR at 64 kbps.
The small comparison I did in the past between different codecs never surprised me and went (for once ) in the same way than common opinion. And I often find mp3 to be a more reasonnable choice than mpc (muffled sound, but low distorsion level). SBR may be helpful, but I'm not sure that time should be spend for tweaking mpc at such bitrate.
I'm not sure if we should give recommendations what Frank should do with his spare time at all, but from what I've heard until now, it would be worth it, because the sound basis seems to be even cleaner than AAC at low bitrates. This is of course only a theoretical assumption, as he would have to pay license fees to Coding Technologies for SBR which will probably never happen. But MPC could probably make use of this bandwidth extension at least as good as mp3PRO and maybe even better than AACplus, because the remaining artifacts are all related to the high-frequency output of the source (like in your favorite harpsichord music).
Another way to optimize this behaviour would probably be a resampling to 32 kHz at low bitrates, and as far as I know this already happens in the new 1.93j encoder (read something about it in the "news" section of Case's homepage). Because until now, --thumb does not resample and so high-pitched notes are bound to make more problems than they would with resampling.
And if Case would implement an online buffer into the Winamp plugin like in the standard in_mp3.dll, I wouldn't even have to wait for a modem-bitrate preset in MPC...
Nice to read positive comments about MPC with low bitrates for a change
And if Case would implement an online buffer into the Winamp plugin like in the standard in_mp3.dll, I wouldn't even have to wait for a modem-bitrate preset in MPC...
Peter has included HTTP streaming for 0.96+ plugins, there's no graphical configuration for it yet but buffer settings and size can be edited manually in musepack.ini.
Nice to read positive comments about MPC with low bitrates for a change
You're welcome... It's also astonishing for me how good --thumb is at cymbal sounds that are placed on the sides of a stereo image, because this always leads to typical flanging sounds with most of the codecs at low bitrates. I think I will upload the demo recording I've encoded yesterday to my homepage, because it has a lot of these cymbals and snare sounds, too. It will also be a good test for the online buffer, because that's the file with 94 kbps nominal bitrate.
And if Case would implement an online buffer into the Winamp plugin like in the standard in_mp3.dll, I wouldn't even have to wait for a modem-bitrate preset in MPC...
Peter has included HTTP streaming for 0.96+ plugins, there's no graphical configuration for it yet but buffer settings and size can be edited manually in musepack.ini.
Indeed...
HTTP_Proxy=
HTTP_ProxyMode=1
HTTP_Prebuffer_Start=25
HTTP_Prebuffer_Underrun=25
HTTP_Buffer_Size=131072
I assume the prebuffer settings are meant in seconds and the buffer size is in bytes? It would be nice if these settings were configurable in the GUI, because most of my friends and relatives are not too good at editing *.ini files. Furthermore you could perhaps offer several "buffer presets" for an easy usage like "28.8k", "56k", "one-channel ISDN" and "two-channel ISDN", so people would immediately know what this is good for.
By the way, is this possible with all input plugins in Winamp? It would help a lot with in_mp4.dll and in_mp3pro.dll, too...
OK....... thanks for all of your comments..... however the sad news is that i only discover that i can't play video ( no matter it is Divx or Xvid ) with MPC as audio as there are no filter for it..... ( YET !!! ) so i may have to wait for a bit or look into solution to how to solove this problem. Thx for all of your help anyway.