Thanks. This I did not know.



Hmm. I don't spend all my life looking out for all that changes in foobar. I'll leave it at that.

Not to mention Milkdrop, which IMHO is more satisfying than a good fireworks display on the right monitor. Of course, it's possible to keep WinAMP around when visualization is desired, and use fb2k for everything else.

At this point, I haven't switched to Foobar, and am not using it. It's a personal (dis)preference for the GUI -- I do care about program interfaces, or I'd be using a text mode OS with no GUI at all. Also, WinAMP sounds just fine to me... my compressed audio files don't clip, as I make them all myself. Just deliver the 16-bit data to the soundcard directly, thanks very much.

Not at all. Foobar, contrary to some reports, is designed primarily for excellent architecture and audio quality. Because of its good architecture, it tends to be leaner than most programs, especially considering its massive functionality. However, it is noticably more costly in terms of CPU cycles, due to the audio quality focus.

In other words, there is no "bloat" advantage. Both FB2K and WA2 are well-designed, bloat-free players. Each has their niche, and FB2K fits my audio playing niche much better than WA2. However, in a bizarre turn of events, WA2 is now my default movie player. Really, though, with visualization support now, I think one of these days we may be shocked to see a basic foobar video plugin from someone. After that, it's just a matter of time before it reads e-mail.

Clipping isn't due to faulty encoding procedure, or even faulty encoders, it's due to lossy formats, so unless you're using lossless or externally compensating for clipping, you'll eventually encounter it. Your equipment just may not be sensitive enough for you to notice.

So do I - but clipping is inevitable when you're dealing with lossy encoders. If the PCM track ripped from a CD peaks at, say, 98%, it's very likely that the encoder will drive the peak beyond full-scale, meaning the audio would be clipped upon decoding. How severe this effect is depends on the encoder used, and on how compressed the music is: "Normal" music which peaks just below or at full-scale but isn't compressed mostly results in peaks just above 100% when encoded to a lossy format; the average compressed CD often reaches ca. 110%, and really insanely compressed music that already has thousands of consecutive clipped samples in the PCM track can easily go as high as 160% or more. Garf once posted a nice example, a Red Hot Chili Peppers CD which provoked a >400% peak when encoded to Ogg Vorbis.


Typical peak values for a non-compressed CD when encoded to lossy (album gain is -2,28dB, the album is from 1984):

0,979675
1,006165
1,038514
0,852779
1,019227
0,907590
0,994690
1,024476
1,016236
1,054262


Compressed 2002 album (album gain: -7.28 dB):

1,091372
1,082827
1,063173
1,088015
1,065798
1,125187
1,140629
1,105228
1,126347
1,100955
1,126713
1,073916
1,119083
1,129154
1,105289


Insanely compressed album (album gain: -12.28 dB):

1,208686
1,239814
1,081301
1,109317
1,201178
1,070803
1,145512
1,105411
1,157781
1,172063
0,894711
1,213569

(These are MPC --quality 7 files. The third album peaked at ~140% when encoded to --quality 5, and at ~160% when encoded to Vorbis -q 2.)

Note that you can only avoid this kind of clipping on playback if you use ReplayGain. It's no problem to playback the audio without clipping in either Winamp or foobar2000, but depending on which format you're using, there are limitations in Winamp. For example, if you use MPC, your only option to prevent clipping is to have the whole file scaled down to the point where it no longer clips. On music with insane peaks (like Garf's RHCP CD, whose volume had to be reduced below the 89dB RG level to get rid of all clipped samples ), this can cause significant volume differences between files (even though you're using ReplayGain). With foobar, you have the option of limiting all peaks that would clip, so you have clipping-free audio with no volume differences caused by scaling.

Another example where foobar's way of handling clipping is superior to Winamp's. Look at these values:



[EDIT] I have no idea why the columns aren't aligned correctly, it worked all right in a text editor using a fixed-width font... [/EDIT]

The third file already clips, but still needs considerable amplification to match the 89dB level. With Winamp, there would be no way to get these 89dB without introducing serious clipping - and with clipping prevention enabled in the MPC plugin, the volume of the file would even be reduced (because, as I said, it already clips as it is). If played between other files, this one would be too quiet. With foobar, you'd just enable the Advanced Limiter, turn off the ReplayGain clipping prevention, and the file would be played back at normal volume, without clipping. (The other two files in the table are similar examples, except that they don't clip as they are. And you don't want to know how the second one sounds if played back without any kind of clipping prevention/limiting. )

At the risk of sounding like a zealot : Like it or not, this actually is a practical advantage, not just a theoretical one.

CU

Dominic

[EDIT] OK Canar, this time you were faster [/EDIT]

Volcano, thanks for the description of the technical differences

The problem is, Dibrom claims that Foobar2000 shines both in theory and practice. Unless we are doing things other than listening to our music, practice to me means an audiable difference?

Again though, I don't run any DSP's as far as I know, so decoding an APE from 16 to 64 bits only to dither back to 16 again is (as someone said) just wasted CPU cycles to me..

Anyway, I think we need MTRH to post some of his drivel again to get this back on-topic (considering the topic title it was given..)

No, that's not necessarily what it means, and stop putting words in my mouth, mmmkay? Thanks.

Now, from an engineering/coding/design point of view (from the point of view of plugin developers/audio format developers/etc), the design of foobar2000 often offers advantages over other players. If you can't understand this point and what it means in an overall sense, then I can't help you there. Just don't try and correlate this with something else and jump to some completely bizarre and incorrect conclusion about what people are trying to say.



This is kind of missing the point again. Oh well...



Trolling the depths...

Just looking for a flame war here, aren't we?

as far as fb2k is concerned:

Practice: Native replaygain support for all formats.
Practice: Extremely well-designed SDK and player
Practice: "Database" will hold metadata for any format, even if it doesn't support persistent file tagging.

Here's the edge foobar has from a practical, engineering point of view: Developing plugins and thereby extending the functionality of fb2k is a breeze. It is simply more (and more easily) extensible than WinAmp.

K, so, what I've gathered from this thread is that hardcore winamp users will die winamp users, and hardcore foobar2k users will die foobar2k users. Now let's all just be friends

- Matt

Funny stuff
I've been looking for a reason to switch to foobar2000, but if I can't hear the difference (relative to the dithering to 16, 24bit MAD decoder), the memory footprint is essentially identical, and I lose my Steve Moss skins, there's no incentive regardless of how technically appealing the underlying code is.