What is a music player?
github.com
github.com
I would love to tell you that VLC (or mplayer or xine or whatever-video-engine) is great to play music, but it is not. And yet, a lot of person use VLC to play music, to our own astonishment.
Therefore, we are working to make the audio part getting better, and we are working hard on that part (next hackdays topic, in December, is only the audio core).
However, except gapless and a correct media library (which we have but is not activated), all the things listed from this article are done in VLC, including resampling, equalizer, loudness, fingerprinting, software amplification... VLC has also a compressor, a parametric equalizer, a spatializer, pitch correction, scaletempo and many downmixers / headphones enhancers. We have also Karaoke support...
Moreover, libswresample is far from being the best quality ever.
So, why don't we have gapless in VLC? Well, because to get correct gapless (not the 50ms you can have with VLC) or cross-fading, you need to have 2 inputs at the same time. And this needs quite a bit of work, notably to be sure to detect correctly EOF.
Thanks a lot for the feedback! I didn't knew that VLC has advanced so much in such functionality like loudness normalization and dynamic range compression. How does it analyze the loudness? Does it also use the ReplayGain spec? What about album-loudness?
It sounds like besides gapless playback and a database, VLC already has everything what a music player needs to have - or what you need that VLC becomes great to play music.
Or is anything missing on the list?
For me, the intelligent automatic queue is, besides the audio quality, a very important element (because it is the way I listen to my music).
A data point about your surprise: I don't like database-like interfaces, just a plain list of songs, taking the minimum screen real state. The only really useful extra feature I like is loudness adjustment per song, and I prefer to set it manually.
But, but VLC has no problem with multiple inputs.
Mosaic is using VLM, but VLC's main playlist does not use it :)
For local media, it would be nice if VLC would (optionally?) remember where one stopped playback, so that one could resume there without having to hunt around or to manually note the location/time.
I don't want to detract from core development (i.e. thank goodness I can view/listen to this stuff reliably and without tackling a plug-in hell). Just one user's anecdote.
P.S. I'll add that initiating recording of a stream that is already playing could be a bit easier. (On Windows, I've found I have to start a second instance of VLC and start recording without first playing the stream.) And, my sincere apology if I've described features that are available but that I've missed or missed the controls for.
Because it runs on every OS most people know about and it plays every file most people are able to feed it.
Also, people have been willing to put up with RealPlayer, which is even worse for playing music.
The number of people using RealPlayer is incredible, indeed.
This is software amplification, so at worse, you clip everything. It's like saying that you should not listen to metal or experimental music because it is more saturated and might destroy your speakers. The software cannot make the difference.
VLC only uses the normal system APIs, so at worse, it will have a fully saturated output, that could be caused by the input OR the software amplification. If the laptop speakers cannot hold what the audio card is outputting, the issue is in the drivers.
Digital clipping is one of the worst things you can do to speakers with a separate high frequency driver - it radically changes the power distribution due to the additional frequencies generated by square wave clipping[1]. This can overload and burn out the driver (depending on its design). Even expensive speakers may not have sufficient protection, or the "conservative" ratings may be not adequate.
I don't know if any laptops come with 2-way (or better) speakers, but lots of computers are connected to such.
[1] http://www.st-andrews.ac.uk/~www_pa/Scots_Guide/audio/clippi...
That aside, I've always perceived some type of limiter-effect whenever I turn up VLC over 100%. Which is not clipping. I never really considered whether this limiting happened in VLC, the OS or my soundcard. It's a small laptop so no fancy soundcards either.
So, checking VLC's preferences, under Advanced>Audio there's an option called "peak protection", which is on by default. Sounds like something that does a type of limiting?
But I may be wrong, I just checked, (apparently my VLC only seems to go up to 200% by default?), but with a sufficiently loud sample, I could definitely hear clipping, instead of limiting.
But, just like your reference says, at the moment you've applied 5x clipping that's pretty extreme. You might as well have a 1-bit waveform at that point because it'll be either up or down. It won't sound like the original any more, at all. If you play that to your expensive speakers at high power, and think it's a good idea to do that for a while, then I really don't think it's VLC's job to protect you from yourself. The only possible excuse might be someone that has a long playlist of quiet sounds, amped up to 400%, leaves and isn't there to correct it when a forgotten loud track starts up. But that scenario is somewhat far-fetched, somewhat stupid and at 400%+clipping still not certain to damage the tweeters much more than loud sounds might do in general, clipped or not.
And another one: http://superuser.com/questions/337265/vlc-sound-boosting
From what i gather on the above thread it turns out that some sound drivers are not that smart and so it ends up damaging the speakers and its not VLCs fault .
Now try "work from home" or "moon landing hoax".
The way we made it work is that every song goes into a list sorted by date last queued, and then we use a parabolic curve which means that any song could theoretically be queued next, but songs that have not been queued the longest have the greatest chance of being queued next.
This is something that is hard to test without trying it out for a long period of time, but I think after one year it is safe to say that it's a pretty damn good algorithm.
The added benefit of using "last queued date" instead of "last played date" is that if Dynamic Mode queues a song, and you skip it because you don't want to hear it, it still moves to the end of the list and becomes less likely to be queued again.
* A music player should show the current song info like title or artist. There is no way to know which is the current song. * A music player should have a clear interface. * Where is the volume? * What is fillUpTo and why it doesn't have spaces? * What is addSome and why it doesn't have spaces? * Why a clear button? * Why the format, time, and more things is being show in the interface. I am a user. Don't worry about that details. * Why input boxes to show the time and current song. Can I change that? * ...
Sorry for not testing but since more than 3 years I was using spotify so I just remove all my files.
To answer some of the questions: The current song is always the blue entry. All the grey entries above it are the recently played songs. Everything below is what comes next. In addition, the artist and title of the current song is displayed at the head. Those aren't input boxes (although they might look as such). The clear button clears the queue. The volume is the slider on the right.
But I agree: The GUI needs much improvement...
It ticks most of the boxes and supports plugins and DSPs, Bauer stereophonic-to-binaural DSP[2] amongst others, and can be extended to suit pretty much every need. :)
One thing I always wanted is for a playlist which have ended to start over if I hit play instead of playing the last song again. Like a cd player would. Never found a solution to that.
Foobar2000 is the player on Windows that I'm still in love with. You can run Foobar on MacOS using Wine, and there's plugins that will use the foobar's http control service to add global hotkeys on Mac.
For instance, I can use xbindkeys to bind "mpc toggle" to my play/pause key.
"Intelligent automatic queue" sounds great along with other features.
The nice thing is that stuff you like bubbles to the top and stuff you don't goes to the bottom. You can do random play by score. Note that it doesn't only play high score stuff, but rather biases towards it, so you do get to rehear lower scoring content, just not that often.
Seriously: A completely different behaviour than normal which would lead to no one finding the music they want to listen to (but finding newly added music easily) should only be the default if you have enough usertests to confirm that they want that. At least if your aim is that many people use your software and not only you plus the two exceptions who like that too.
Either way, I don't think I am one of two people, and I think the tone of your last comment was very poor. As a rule: think first, then post.
I'm sorry if one could interpret my writing as poor tone. I indeed think that only a very small minority of people would like that, but that is totally ok and it was not meant as an attack. The point was that you have to determine such things, find out wether your potential customers would like that, if you are targeting people at all. If not, it doesn't matter.
>As a rule: think first, then post.
Spare me the bullshit. To say I didn't think before writing is a totally unnecessary attack - I clearly made a legitimate point.
Yeah, well, just because it's the internet and you can't see people's reactions, it doesn't mean that it suddenly becomes acceptable to imply that people are selfishly only thinking about their own user experience...
>> I indeed think that only a very small minority of people would like that [...] The point was that you have to determine such things, find out wether your potential customers would like that, if you are targeting people at all. If not, it doesn't matter.
Right, well the problem here is that you haven't heeded your own advice. You're sitting here telling me about "very small minorities" with no evidence to back up your claims. And I tend to think: absence of evidence, intuition should trounce mere opinion. (That said, I agree that if somebody hasn't added music to their collection for a long time, a time-ordered view would make less and less sense. I think that's intuitive, too.)
In this project, there is no such view yet so there is no way. But it is easily possible to add such criteria to the intelligent queuing algorithm which will have the effect that new songs gets selected more likely.
Though you probably didn't want to answer my comment, but the one above: Sure think that this is the way to go, either being able to sort the library accordingly, or better by something like your intelligent queuing algorithm. But the suggestion i objected was to have this as the default-sort-setting of the library.
Code is here: https://github.com/albertz/music-player/blob/master/queue.py
Esp. `MainQueue.calcScore` is what you would want to modify.
Alternatively, a manual approach would be that if I hear a song I know should segue into another, I'd like to be able to suspend shuffle and have it instead pick up from the song that would generally follow that song in the track order of the source album.
Code is here: https://github.com/albertz/music-player/blob/master/queue.py
Look at `MainQueue.calcScore` and others.
For the manual approach, maybe some button next to a song like "add follow-up songs to this song below" would do (not sure how I would insert that into the GUI, though).
1. http://www.winamp.com/media-player/all (on the bottom)
I had similar problems to find any totalcmd replacement.. and again, there isn't anything close (I ended up with Krusader I think, but it wasn't anywhere near).
Good post, interesting read. :)
For example they have their own loudness analyzing specification called Sound Check. A music player having its own loudness specification and analyzing algorithm is very rare! Most players don't have support for analyzing at all and if they do, they usually use the original mp3gain algorithm to calculate the ReplayGain value (but as that one is GPL, this is only for GPL players).
The overall audio playback quality is quite good.
Also they have a lot of other advanced features.
E.g. the iTunes DJ mode is actually not so bad. The algorithm behind it works quite good.
They also have a remote interface where users could vote for different songs and the song with the highest votes will get played next.
Or directly here for a previous discussion: http://www.reddit.com/r/opensource/comments/1224ux/experimen...
Actually it lacks many of the most important features.
https://www.gittip.com/albertz/
and Flattr:
http://flattr.com/thing/49143/Projects-artworks-writings-of-...
Consider supporting him financially, if you like his work.
In fact, why they didn't just use MPD escapes me.
MusicPlayer is already highly modular. Adding a server interface listening on some TCP port is trivial at this point. Full control via an IPython shell or just the console is already possible. (In the beginning, while it didn't had any GUI, the IPython shell interface was how I used it.) There is nothing really complicated in developing some remote control.
The way MusicPlayer manages the queue, i.e. the intelligent automatic main queue is not trivial/straight-forward to emulate in MPD and it would be hacky - that is the first and main reason I didn't used MPD. Then, using MPD wouldn't really have made it simpler, only more complicated. Forking MPD itself and extending/changing it in the way I intended would maybe have been a solution but I thought it would be simpler to just code the player engine from scratch. Despite that, MPD does not support many of the current features of MusicPlayer, like the builtin loudness analyzing algorithm, etc.
Please, no. Some of us don't use desktops and don't want drag-n-drop dependencies. (I know this is currently built for Cocoa, but the project's goal is cross-platform.)