If you encode your music more often than you listen to it, then this would be a problem:) Seriously though - the current Vorbis encoder is not particularly optimised, and where it *is* optimised it's for the PPC (very few of the Vorbis developers use x86, for some reason).
There's already some optimisation work underway for RC4 - mainly in reducing the memory needed to decode, which will be useful for those hardware implementations if/when they arrive...
Rubbish.
The raw score was slightly higher in one of the three samples, but by 0.03 - and the more detailed analysis below shows that, for that sample, *there were NO statistically significant results*. There was nothing even *close* to statistical significance. I realise understanding more than 1 number may be a strain, but it's necessary.
Now, for the second sample there were only two significant results (AAC and Ogg being better than Xing) - and those would only have been significant if you had set up the whole experiment specifically to test whether AAC and Ogg were better than Xing. Given that we are asking a general question, we need stronger statistics -- and as a result for our general question there were no statistically significant results for this sample either.
The third sample is the only one with general significant results -- very strong ones at that. And they say that on this sample, Ogg, MPC and AAC were better than WMA8 (LAME may be as well, but the result is a little off the required significance level).
So, given these samples, and these listeners, we can only conclude that WMA8 is certainly not the best codec at 128kpbs. This doesn't imply anything about performance at other bitrates, of course. (WMA8 is probably still the best at 64kpbs, for example).
Re:A small question
on
Non-MP3 Codecs?
·
· Score: 2, Informative
Everyone else is assuming that you are using Linux. Just in case you are using Windows, the best two options are:
1) CDex. Has an Ogg encoder (RC2 version) embedded, and you can use the command line RC3 version with it very easily. The latest betas use the 'cdparanoia' libraries to rip. This would be nice choice once it's been updated to RC3.
2) EAC. This is the benchmark for quality ripping in Windows. It's slightly harder to set up, and doesn't integrate as nicely with passing metadata to the external ogg encoder, but it's the best Windows ripper bar none.
Both pieces of software are free. CDex is also open source (useful if you happen to have a copy of VC++ floating around).
Ok - one more. This'll take me from 44 to 41 karma. I've been wanting to reduce my karma for a while now, but don't like trolling -- however given that anything posted to this is being modded down by a 'punishment' script, I can reduce karma without guilt:)
Luckily, it works perfectly in current KDE CVS, which will become KDE3 in a couple of months time... they've just about implemented all of Javascript that anyone cares about now:) (including the javascript: URLs).
Exactly -- there's no point having a language binding where the API changes every day and a half, or where only 10% of the original functions are bound.
Look at how long it took to get half way decent Gnome C++ wrappers.
I tried out Mandrake 8.1 a while back, and couldn't believe how often everything crashed -- they must compile everything with '--make-unstable'. I switched to Redhat 7.2 (I know, I'm not a true diehard - been there, done that, now I want the easy life:), and with my own compiles of KDE very rarely see anything crash.
In fact (as you say), just about the only things that *do* crash are bits of Konqueror. Javascript in KDE2 is known to be a bit buggy -- it's been cleaned up and extended in KDE3, enough that it'll be enabled by default.
(KDE3's looking good, by the way - I advise you to switch to it when it comes out. Compile it yourself as well, it's just as easy as getting packages.)_
But I agree here, disabling Javascript by default is not good, IMO. They should really enable it by default.
Apparently, it'll be enabled by default with KDE3. (oh, and they've put magic desktop borders back in kwin for KDE3 as well, which makes me happy - that's another piece of functionality that I miss from Sawmill/FVWM/whatever).
Archive browsing. Basic package management. Anything else even the simplest file manager can handle but Nautilus doesn't because the developers are too busy trying to get the HTML display somewhat stable or drawing purty themes.
Agreed. I was really happy when they announced that they'd be working on a replacement for GMC (which was a truly terrible hack of a file manager). However, they seem to have come up with something that has a very pretty shell, with no depth to it. How could they not put archive browsing in, for example? That alone means that I'm going to stick with Konqueror as my file manager.
$30 million developing the damn thing, and they couldn't spend the time to write some virtual filesystem drivers...
(that said - the binary NNTP file view for Nautilus mentioned in the recent Gnome news is pretty nice - but things like this should have been in place when Nautilus 1 was released, not years later).
The most annoying thing is that when I select some text and press the middle mouse button to paste it somewhere, nothing happens.
Yes, and the first thing I type at a DOS command prompt is 'ls'... then I have to stop and think for a second when it doesn't work:)
You'd be amazed at the number of people using KDE who say that copy-paste doesn't work, because they haven't bothered to do a little reading and discover the standard middle button pasting scheme. The same goes for focus-follows-mouse, although KDE have chickened out and made click-to-focus the default (why? it's never seemed more convenient to me).
Similarly, a lot of people say that Javascript in Konqueror is completely broken, not realising that in KDE2 Javascript is *disabled* by default because it's a potential security risk.
Re:The first Slashdot troll post investigation
on
KaZaa Suspends Downloads
·
· Score: -1, Offtopic
Actually - fuck it, mod this one down as well. Being stuck at the karma cap for so long takes all the fun out of life.
Re:The first Slashdot troll post investigation
on
KaZaa Suspends Downloads
·
· Score: -1, Offtopic
50 replies this this, and they have *all* been moderated down to -1 -- are there even that many mod points kicking around normally?
Well, go ahead and knock this down as well - it'll be the first time I'll have been modded down for years, and I could do with some karma breathing space.
"""
Jack, in a future firmware upgrade we will support Ogg Vorbis, currently we do not. As for a speculation on when it will be supported, I will find out from our engineering team and let you know. Let me know if you have any further questions.
Cheers,
Christopher Lee Papazian
Marketing Manager
iRiver America, LLC
"""
Re your moaning: I wanted to buy a decent inkjet printer with good Linux support. Only took me about half an hour to find that the best bet was the Epson C80, which has *excellent* drivers from the gimp_print project.
Next time you are buying something, ask them if it has Linux support. If they say no, don't buy it - and tell them that you are not buying it *because it doesn't have Linux support*. If enough people do that, they'll quickly get the message. Don't blame Linux for HP's shoddy standards.
I don't get why we're supposed to fly into a rage because Microsoft decides that paying attention to customers and giving them what they want for a better price is a good idea
Exactly. If MS really *can* provide a better deal than Linux, then companies *should* go for them (noting that 'better deal' includes things above and beyond price). I don't see what is so amazing and unexpected about this email.
All a window manager does is manage windows. No file manager, no web browser, no panels.
Both KDE and Gnome (and XFCE) are desktop environments, and include within them a window manager (kwin for KDE, sawfish for GNOME, xfce's built in windowmanager for XFCE).
Both the KDE and Gnome environments work perfectly well using different window managers (a lot of people used to run KDE with the Blackbox window manager, as with Gnome and a window manager called Enlightenment).
Mosfet writes some good code, but don't go away thinking that KDE is lost without him (particularly not because of this recent contributution of some effects ripped from imagemagick). This is so far away from the truth as to be laughable.
One of the biggest things to happen to KDE in last year has been the rewrite of KDE's printing support, by Michael Goffioul. No-one goes around proclaiming Michael as a coding god, because he just got on with it and produced something very impressive (and that has got even more impressive in KDE 3).
Similarly for the developer(s) of Kate, KDE's text editor. Or the developers of Konqueror, who have equalled Mozilla with a twentieth of the personnel and a thousandth of the money.
Similarly for all the people that don't code, but instead translate KDE into 15 million languages.
KDE is a true team effort and can do without coding primadonnas.
Re:Anyone know a quick way to convert an MP3 libra
on
Ogg Vorbis RC3 Released
·
· Score: 2, Informative
Yes - if you want to support Ogg Vorbis then *don't transcode* - Re-rip to Ogg. Otherwise all the file sharing networks will be flooded with poor quality Oggs, and we'll be no better off than we were with MP3s.
First - you say it's a drawback that Ogg at 117kpbs sounds better than MP3 at 128kpbs? I don't understand your point.
Second - LAME's legal status is unclear. The MP3 patents are not (only) in psychoacoustics, they affect the basic MP3 file format, together with natural (obvious) optimizations you would use in creating an MP3. LAME *does* infringe these patents.
The Ogg Vorbis *decoder* has been stable since RC1, and will be able to play any Vorbis stream produced by RC2, RC3, 1.0, or whatever. There are slight problems in that the reference decoder is floating point, which doesn't fit well with the ARM chips a lot of hardware players use, but that'll be sorted eventually.
RC3 is much better quality all round than RC2 (and RC4 will be better quality than RC3 particularly for low bitrates). Particularly, RC2 had some problems with high frequencies that have now been fixed.
So reencode - and use '-q' switches this time instead of '-b' switches...
Re:Double Blind Listening Tests... Where ???
on
Ogg Vorbis RC3 Released
·
· Score: 5, Informative
We're getting there. RC3 has only been released for about an hour:)
The best tests we have at the moment were conducted by
ff123 at 128kpbs. There have been two so far (the second is technically still underway, although it's now based on outdated encoders, so I imagine a third will start fairly soon). The
first listening test compared RC2 Ogg Vorbis, LAME MP3, Xing MP3, Liquifier AAC, MPC, and WMA8. The formal analysis showed that, on the file compared, the encoders could be divided with 95% confidence into three groups (from best to worst):
MPC and AAC
WMA8 and LAME and OGG
XING
.
The second test used a CVS version of OGG from about a month and a half ago. This time there are three test samples which participants can choose to evaluate. While technically still underway,
the interim results can be found here. Of the three test samples, the first can't discriminate between the encoders, the second looks like it will but needs more listeners (and the results so far look interesting), and the third discriminates well, to the extent that it shows that Xing and WMA8 are statistically much worse on that clip than all the others.
Now all we need is a third test with the latest updates of all the encoders - since we now have a new stable version both of Ogg Vorbis (RC3) and LAME (3.91).
Slashdot Mirror
but not too impressed with encode speed.
:) Seriously though - the current Vorbis encoder is not particularly optimised, and where it *is* optimised it's for the PPC (very few of the Vorbis developers use x86, for some reason).
If you encode your music more often than you listen to it, then this would be a problem
There's already some optimisation work underway for RC4 - mainly in reducing the memory needed to decode, which will be useful for those hardware implementations if/when they arrive...
Rubbish.
The raw score was slightly higher in one of the three samples, but by 0.03 - and the more detailed analysis below shows that, for that sample, *there were NO statistically significant results*. There was nothing even *close* to statistical significance. I realise understanding more than 1 number may be a strain, but it's necessary.
Now, for the second sample there were only two significant results (AAC and Ogg being better than Xing) - and those would only have been significant if you had set up the whole experiment specifically to test whether AAC and Ogg were better than Xing. Given that we are asking a general question, we need stronger statistics -- and as a result for our general question there were no statistically significant results for this sample either.
The third sample is the only one with general significant results -- very strong ones at that. And they say that on this sample, Ogg, MPC and AAC were better than WMA8 (LAME may be as well, but the result is a little off the required significance level).
So, given these samples, and these listeners, we can only conclude that WMA8 is certainly not the best codec at 128kpbs. This doesn't imply anything about performance at other bitrates, of course. (WMA8 is probably still the best at 64kpbs, for example).
1) CDex. Has an Ogg encoder (RC2 version) embedded, and you can use the command line RC3 version with it very easily. The latest betas use the 'cdparanoia' libraries to rip. This would be nice choice once it's been updated to RC3.
2) EAC. This is the benchmark for quality ripping in Windows. It's slightly harder to set up, and doesn't integrate as nicely with passing metadata to the external ogg encoder, but it's the best Windows ripper bar none. Both pieces of software are free. CDex is also open source (useful if you happen to have a copy of VC++ floating around).
Ok - one more. This'll take me from 44 to 41 karma. I've been wanting to reduce my karma for a while now, but don't like trolling -- however given that anything posted to this is being modded down by a 'punishment' script, I can reduce karma without guilt :)
Moderation Totals: Offtopic=130, Flamebait=3, Troll=4, Redundant=3, Insightful=24, Interesting=76, Informative=17, Funny=3, Overrated=2, Underrated=20, Total=282.
Luckily, it works perfectly in current KDE CVS, which will become KDE3 in a couple of months time... they've just about implemented all of Javascript that anyone cares about now :) (including the javascript: URLs).
Exactly -- there's no point having a language binding where the API changes every day and a half, or where only 10% of the original functions are bound.
Look at how long it took to get half way decent Gnome C++ wrappers.
I tried out Mandrake 8.1 a while back, and couldn't believe how often everything crashed -- they must compile everything with '--make-unstable'. I switched to Redhat 7.2 (I know, I'm not a true diehard - been there, done that, now I want the easy life :), and with my own compiles of KDE very rarely see anything crash.
In fact (as you say), just about the only things that *do* crash are bits of Konqueror. Javascript in KDE2 is known to be a bit buggy -- it's been cleaned up and extended in KDE3, enough that it'll be enabled by default.
(KDE3's looking good, by the way - I advise you to switch to it when it comes out. Compile it yourself as well, it's just as easy as getting packages.)_
But I agree here, disabling Javascript by default is not good, IMO. They should really enable it by default.
Apparently, it'll be enabled by default with KDE3. (oh, and they've put magic desktop borders back in kwin for KDE3 as well, which makes me happy - that's another piece of functionality that I miss from Sawmill/FVWM/whatever).
Archive browsing. Basic package management. Anything else even the simplest file manager can handle but Nautilus doesn't because the developers are too busy trying to get the HTML display somewhat stable or drawing purty themes.
Agreed. I was really happy when they announced that they'd be working on a replacement for GMC (which was a truly terrible hack of a file manager). However, they seem to have come up with something that has a very pretty shell, with no depth to it. How could they not put archive browsing in, for example? That alone means that I'm going to stick with Konqueror as my file manager.
$30 million developing the damn thing, and they couldn't spend the time to write some virtual filesystem drivers...
(that said - the binary NNTP file view for Nautilus mentioned in the recent Gnome news is pretty nice - but things like this should have been in place when Nautilus 1 was released, not years later).
The most annoying thing is that when I select some text and press the middle mouse button to paste it somewhere, nothing happens.
:)
Yes, and the first thing I type at a DOS command prompt is 'ls'... then I have to stop and think for a second when it doesn't work
You'd be amazed at the number of people using KDE who say that copy-paste doesn't work, because they haven't bothered to do a little reading and discover the standard middle button pasting scheme. The same goes for focus-follows-mouse, although KDE have chickened out and made click-to-focus the default (why? it's never seemed more convenient to me).
Similarly, a lot of people say that Javascript in Konqueror is completely broken, not realising that in KDE2 Javascript is *disabled* by default because it's a potential security risk.
Offtopic=30, Troll=1, Redundant=2, Insightful=8, Interesting=22, Informative=7, Overrated=2, Total=72.
Actually - fuck it, mod this one down as well. Being stuck at the karma cap for so long takes all the fun out of life.
50 replies this this, and they have *all* been moderated down to -1 -- are there even that many mod points kicking around normally?
Well, go ahead and knock this down as well - it'll be the first time I'll have been modded down for years, and I could do with some karma breathing space.
http://www.hydrogenaudio.org/forums/showthread.php ?s=&postid=6532
To paraphrase:
"""
Jack, in a future firmware upgrade we will support Ogg Vorbis, currently we do not. As for a speculation on when it will be supported, I will find out from our engineering team and let you know. Let me know if you have any further questions.
Cheers,
Christopher Lee Papazian
Marketing Manager
iRiver America, LLC
"""
Re your moaning: I wanted to buy a decent inkjet printer with good Linux support. Only took me about half an hour to find that the best bet was the Epson C80, which has *excellent* drivers from the gimp_print project.
Next time you are buying something, ask them if it has Linux support. If they say no, don't buy it - and tell them that you are not buying it *because it doesn't have Linux support*. If enough people do that, they'll quickly get the message. Don't blame Linux for HP's shoddy standards.
Put the taskbar at the *top* of the screen, where God intended it to be (at least that's what he told me over a beer last Wednesday).
There is research underway to produce Ogg Tarkin, which will be the video branch of the Ogg media framework.
Sadly, it seems a lot harder to do video than audio, especially while remaining patent free (as all the Ogg projects have to).
Exactly. If MS really *can* provide a better deal than Linux, then companies *should* go for them (noting that 'better deal' includes things above and beyond price). I don't see what is so amazing and unexpected about this email.
All a window manager does is manage windows. No file manager, no web browser, no panels.
Both KDE and Gnome (and XFCE) are desktop environments, and include within them a window manager (kwin for KDE, sawfish for GNOME, xfce's built in windowmanager for XFCE).
Both the KDE and Gnome environments work perfectly well using different window managers (a lot of people used to run KDE with the Blackbox window manager, as with Gnome and a window manager called Enlightenment).
'kwin' is actually a fairly lightweight window manager. Or do you not know the difference between a window manager and a desktop environment?
One of the biggest things to happen to KDE in last year has been the rewrite of KDE's printing support, by Michael Goffioul. No-one goes around proclaiming Michael as a coding god, because he just got on with it and produced something very impressive (and that has got even more impressive in KDE 3).
Similarly for the developer(s) of Kate, KDE's text editor. Or the developers of Konqueror, who have equalled Mozilla with a twentieth of the personnel and a thousandth of the money.
Similarly for all the people that don't code, but instead translate KDE into 15 million languages.
KDE is a true team effort and can do without coding primadonnas.
Yes - if you want to support Ogg Vorbis then *don't transcode* - Re-rip to Ogg. Otherwise all the file sharing networks will be flooded with poor quality Oggs, and we'll be no better off than we were with MP3s.
Two things.
First - you say it's a drawback that Ogg at 117kpbs sounds better than MP3 at 128kpbs? I don't understand your point.
Second - LAME's legal status is unclear. The MP3 patents are not (only) in psychoacoustics, they affect the basic MP3 file format, together with natural (obvious) optimizations you would use in creating an MP3. LAME *does* infringe these patents.
There are plans afoot.
The Ogg Vorbis *decoder* has been stable since RC1, and will be able to play any Vorbis stream produced by RC2, RC3, 1.0, or whatever. There are slight problems in that the reference decoder is floating point, which doesn't fit well with the ARM chips a lot of hardware players use, but that'll be sorted eventually.
RC3 is much better quality all round than RC2 (and RC4 will be better quality than RC3 particularly for low bitrates). Particularly, RC2 had some problems with high frequencies that have now been fixed.
So reencode - and use '-q' switches this time instead of '-b' switches...
The best tests we have at the moment were conducted by
ff123 at 128kpbs. There have been two so far (the second is technically still underway, although it's now based on outdated encoders, so I imagine a third will start fairly soon). The
first listening test compared RC2 Ogg Vorbis, LAME MP3, Xing MP3, Liquifier AAC, MPC, and WMA8. The formal analysis showed that, on the file compared, the encoders could be divided with 95% confidence into three groups (from best to worst):
- MPC and AAC
- WMA8 and LAME and OGG
- XING
.The second test used a CVS version of OGG from about a month and a half ago. This time there are three test samples which participants can choose to evaluate. While technically still underway,
the interim results can be found here. Of the three test samples, the first can't discriminate between the encoders, the second looks like it will but needs more listeners (and the results so far look interesting), and the third discriminates well, to the extent that it shows that Xing and WMA8 are statistically much worse on that clip than all the others.
Now all we need is a third test with the latest updates of all the encoders - since we now have a new stable version both of Ogg Vorbis (RC3) and LAME (3.91).