![[lang]](/images/eye.png)
Mirage |
2007-08-31
|
Miguel links to Mirage, which looks cool. At least, until you read the one bit of text that Miguel didn't quote in his blog, which is the list of dependencies. Sox ? mpg123 ? ogg123 ? faad ?
So you write a plug-in for a player that uses an excellent media framework that supports a lot more formats than just mp3, Vorbis and AAC, and you do it using 90's single-purpose libraries ?
Here's how Mirage could have actually been useful:
- write a simple GStreamer element that analyzes decoded audio for this similarity information
- write the Banshee playlist plug-in that interfaces with this GStreamer element
Now it's just like getting a car, then buying a nice horse that you put in the trunk to increase the horse power of the car.
 UPDATE:
the author commented that he chose mpg123 for speed reasons, claiming that GStreamer is a lot slower. Apparently for him libmad is already 4-5 times slower than mpg123. I did a quick comparison between mpg321 (the free version of mpg123) and GStreamer with the mad decoder, and the mad decoder is actually a little bit faster.
In any case, it seems my lowly Pentium IV 1.3 GHz laptop decodes 3 minutes of mp3 in 4 seconds. That's about 50 times faster than realtime. I just checked - my current Rhythmbox library is about 19446 songs, for around 58 days. So using GStreamer, the decoding part of the analysis would take a bit more than a day. A day or 6 hours, the difference to me is pretty much the same. It's not immediately usable, and it's not an impossibly long wait either.
I'd much prefer the ability to use it from any application, and on any sound format supported by GStreamer.
I’m not involved with mirage but according to the home page the algorithm was the developer’s master thesis. It makes sense than when you’re trying to develop an algorithm you concentrate on it, not on the surrounding infrastructure, so he choose the quickest and simplest way to generate wav files, avoiding the complication of depending on gstreamer and having to dedicate lot of time to understanding how it works. I’m sure that he published the plugin so that there’s something “visible” to attract help from others.
Comment by Giorgio — 2007-08-31 @ 10:06
He is using the tools to convert the songs to wav, see mirage-decoder.in. How could he achive the same thing with gstreamer in less than 40 lines of code? Seems improbable to me since there isn’t even any Gst# bindings..
Comment by Björn — 2007-08-31 @ 13:43
mpg123 is used because it is the fastest mp3 decoder available. with gstreamer (I’ve tried this) decoding an MP3 is really slow.
greetings,
dominik.
Comment by Dominik Schnitzer — 2007-08-31 @ 13:44
“Please note that MPG123 is needed for performance reasons. Gstreamer takes about 20 times more time to decode an MP3”
Perhaps you should have quoted this.
Comment by Anonymous — 2007-08-31 @ 13:48
It would be really nice to update your post to reflect this – I tried using gestreamer but it was too slow for this project (analyzing and computing the similarity models)
thanks,
domi.
Comment by Dominik Schnitzer — 2007-08-31 @ 14:09
So what’s with the developer’s comment on the Mirage page?
Please note that MPG123 and those other tools are needed for performance reasons. Gstreamer takes much more time to decode an MP3 than MPG123. We need to decode your MP3s to analyze (‘listen to’) them.
Comment by Götz Waschk — 2007-08-31 @ 14:27
The Mirage creator just sent a post to the Banshee list (http://mail.gnome.org/archives/banshee-list/2007-August/msg00086.html) where he mentions he chose those libraries for speed, but is open to discussion about that decision. From what he says, it sounds like he found Gstreamer to be more than 4 times as slow. It’d be great to get your feedback on the list.
Comment by Gabriel — 2007-08-31 @ 17:28
Why did you delete my comments?
There is a difference if analyzing an MP3 collection takes 12 hours or 200…
Comment by Dominik Schnitzer — 2007-08-31 @ 17:47
@bjorn: if you want to be pedantic, you could say that gst-launch can be invoked just like mpg123, in one line of code. In any case, Aaron seemed to be able to write Banshee just fine. There are unmaintained Gst# bindings, mostly because people writing C# apps with GStreamer use pinvoke. (pinvoke sounds like a blessing and a curse to me, because it means one can get away with not having to write bindings.)
Comment by Thomas — 2007-08-31 @ 18:42
@Dominik, I didn’t delete your comments, they go in a moderation queue. Comments have said that GStreamer is “slower, 4 times slower, 20 times slower.”
I did a quick test:
(This is with mpg321, btw, mpg123 is not even packaged for Fedora)
Doesn’t seem a factor of 20 or 4 to me. And it doesn’t seem slower either. I’ll see if I can compile the original mpg123.
So I’d be interested in seeing how you get it to be 20 times slower.
Also, how are you planning to index my FLAC/monkeysaudio/shorten/wavpack/wma files ? How are you planning to get your plugin distributed legally with banshee ?
Comment by Thomas — 2007-08-31 @ 18:49
With all due respect and imho, joo are a little hard on him thomas !
I think the vast majority of this kind of thesis work is lisp scripts working
on .au files and which dump filenames in a terminal :>
So in fact it’s already quite nicely packaged ! (Now in the long run I do think
you’re right, but maybe it’s “enhancement” vs. “be actually useful)
Comment by Stefan — 2007-08-31 @ 22:28
I’m not sure it’s fair to use the thesis defense. Thesises don’t usually plug in to player software like Banshee. And I’m not bringing his thesis work down either, I’m sure it’s excellent stuff. Really, it doesn’t even matter, from a software perspective, if it is coming from a thesis or not.
I think it’s fair to complain about wrong choices in a plug-in to a player that uses a framework, when the plug-in does not use the framework. Obviously, the thesis author wanted his software to be used, because he went to the trouble of writing a plug-in. When he does, I think it should be evaluated as such, not as a thesis work.
Comment by Thomas — 2007-09-01 @ 10:27
* When he does, I think it should be evaluated as such, not as a thesis work.
I think the point is that he (and a lot of other people) have evaluated Gtreamer and found the same problem that it has suffered from since the project started — it is very, very slow*. It also crashes a lot.
* Yes, that’s the framework that is slow not the decoder. Gstreamer was poorly designed, and it has been shockingly poorly implemented since… mostly by your company.
Comment by Bozy — 2007-09-01 @ 11:03
Whether GStreamer is faster or slower for audio decoding, it would be really nice to have this analysing feature in a GStreamer plugin. Therfore it would be possible to chain this scan with others like rganalysis without scanning the whole library twice.
Comment by buz — 2007-09-01 @ 17:17
@Boxy: trolling doesn’t get you anywhere in life. Hard facts do. It used to crash a lot before “my company” started working on it. Feel free to point me to bug reports you’ve filed since for crashers. Don’t attach your little train wagon to his complaint, because he is complaining about libmad being slower than mpg123. Come up with some hard facts instead of with some general whining, or point us to the shockingly well implemented framework you’ve come up with.
Comment by Thomas — 2007-09-02 @ 07:02
I find it interesting that he finds Gstreamer too slow, and yet he coded the app in C# and used it with Mono. Comedy in action my comrades.
Comment by irony — 2007-09-02 @ 08:12
Thomas, mpg321 has nothing to do with mpg123 performance-wise. Evaluating the performance of mpg123 by running an entirely other program (mpg321) is simply ridiculous. It’s like saying “Opera is slow, look at the following benchmark (note: the benchmark was done using Firefox, as I don’t have Opera”. It is an accepted fact that mpg123 is faster (and possibly “better”) than libmad, and Gstreamer. It simply wasn’t widely used because it wasn’t GPL for a long time.
Next time, please base your scientific arguments on experiments using scientific methods.
Comment by theefer — 2007-09-03 @ 06:51
Uhh… mpg321 ( a clone of mpg123 ) uses libmad, so comparing against it with gstreamer & mad should give you around the same cpu usage. The real Mpg123 does decoding on its on and uses lots of little tricks to get maximum performance.
Comment by Anonymous — 2007-12-18 @ 00:13
WOW comparing gstreamer and mpg123 by …using mpg321 instead of the original!
A program that is written from scratch, the only similarity being _the_interface_.
Talk about lame, lame, lame, Machiavellian tactics (also known as FUD in the software world).
Either that, Thomas, or you know nothing about software.
PS. Feel free not to publish my comment if you want so. I was just surfing the web (searching info about mpg123!) and reached this page by chance.
Comment by random-surfer-321 — 2008-04-18 @ 07:15
mpg321 and mpg123 are completely different code bases. mpg321 uses libmad. mpg123 is easily 2 times faster than mpg321 from my tests on many machines.
Comment by Witold — 2021-01-09 @ 11:28