The Free Software Foundation has launched its Play Ogg campaign for a “legally, ethically and technically superior audio alternative to the proprietary MP3 format”.
Even though Ogg Vorbis truly is legally, ethically and technically superior to MP3, I doubt this will turn the market for downloadable music upside-down. The superior product often doesn’t triumph.
V2000, anyone?
I think the problem is people don’t care. Heck, the iPod – in the public’s mind – is an “MP3 player” even though most people rip in iTunes using default settings and end up with 128K AAC files or buy them from the iTunes store.
I also have to say it took me a bit of searching to actually find a list of players that support it – it isn’t linked to properly from the press release, nor from xiph.org or vorbis.com. You’d think such a link would be prominently on the home page.
So technology asside, they have a big marketting problem!
For me lossy compressed audio is over anyway. Cute for streaming, but I don’t see the point in encoding my CDs in anything other than lossless – ALAC in my case because it is just so easy when using an iPod.
But I agree with the freedom part; I’d love for Vorbis and FLAC to replace MP3, AAC and WMA as “standards”.
People definitely don’t care and it’s easy to see why: because they don’t personally experience the disadvantages of one codec over the other. As such, you could argue that those disadvantages don’t really exist in practice.
And yes, it’s clear to see that MP3 player has become a blanket term for any device that plays files of digitised music.
That said, more could have been done to alert the public to the advantages of Ogg Vorbis over MP3. Flac, on the other hand, comes from the same source and is managing to make inroads into the marketplace. That’s because the lossless world is much less decided at this point in time, so Flac is becoming the de facto there.
As for the point of lossy formats these days, many people still need small files for their portable devices. If I stored music in Flac for use around the house, I would still need to encode to Ogg as well, for use on my mobile devices. Since I don’t want to store two copies of everything, I use only Ogg, which is good enough that I can’t hear the difference, anyway.
So, you might reverse the question and ask: what’s the point of lossless if you can’t hear the difference?
I would still fit over 1000 songs (75 albums) on my 30GB iPod, which is plenty. But yeah, it is not really viable for those with a small flash player; a 4GB nano would fill up rather quickly…
I don’t hear much difference between 256 kbps MP3s and ALAC or the original CD either (though I do easily at bitrates below 192). But one major advatage is that you can also re-code to a different format without losing any more quality – just in case the format I have chosen now goes out of fashion in the future. Going from one lossy encoding scheme to another will lose you even more.
I have a 60 Gb iAudio X5, but it would still annoy me to not have the bulk of my music collection with me whilst on the move. In that case, I’d need to dream up some scheme to sync only the music that I’ve listened to a lot lately, purchased recently, had its mtime recently changed, etc. For a lot of people, this is a non-issue.
As for ALAC, it’s a proprietary container codec, which is always a concern, given the constantly changing face of computing. Happily, it’s been reverse-engineered and a decoder is now available in libavcodec, but it’s still not something I’d be comfortable with.
As always, it’s a case of horses for courses. It’s good to have options and, as you know, I like to keep mine as wide open as possible.
As you point out, my worst problem is having a lossy format as my basis, which means I can’t efficiently convert from one format to another. So far, that hasn’t been an issue.
I gave up trying to have a player big enough to keep all, so I had to choose anyway. I simply have a couple of playlists, one of which is simply called “albums”, where I drag whole albums that I want to be on the player. I then tell iTunes to sync just those playlists.
The reverse engineered ALAC is a good development, but not a requirement for me to ever transcode to something else. As it is supported by the CoreAudio framework on OS X, it is a dodle to write an app that converts ALAC all to another CoreAudio codec. (there is an Vorbis and FLAC Core Audio library too!)
So currently my files aren’t exactly free (as in speech) or open, but I certainly have an exit strategy open if ever required. Which no doubt will happen; no format lasts forever but at least we are now in a better position than ever to keep converting our data to new formats in the future. Compare that to the tapes and punch cards of yesteryear which could only be read by the machines that replaced them at great cost and effort. (and so most organisations never bothered migrating until it was too late)
Correct me if I’m wrong, but Core Audio is not open, is it? Theoretically, Apple could drop support for it or ALAC at any time. They could also go bankrupt. What then?
Proprietary software is exactly like the punch cards and tapes of the mainframe and mini eras, because you’re locked into the technology.
In fact, it’s even worse in my view, because the technicians of the time hadn’t yet learned the hard lessons of the perils of investing in proprietary technology. Even if they could have foreseen the folly of it, there were no open systems or standards to choose from at that time.
Today, there are far fewer reasons to knowingly invest in proprietary technology.
The libavcodec reverse-engineering work gives you your only non-vendor escape route from ALAC back to the free world. As such, it’s a lifeline cast out to the digital dinghy on which you have voluntarily cast yourself adrift!
Joking aside, you and I have clearly differing views of the severity of the problem. To illustrate, you use a non-free application on a non-free operating system to encode your music to a non-free format. All three types of non-free software in the previous sentence are easily avoidable and unnecessary compromises in my view.
Of course, my own life is not free of such compromises, although I do try to carefully consider each one that I make to ensure that it’s not in an area significant enough that it may come back later on to bite me.
What then? I’ll install an older version that still has it! Sure, you can’t easily jump 10, 20 years back to revive some old data you all of a sudden want back, but this is the kind of thing you activiely notice changing and it won’t be too late to a) not upgrade until you convert or b) install the older version on some older hardware you most likely still have around.
The problem with the old punchcards and minis wasn’t software related at all; new systems were usually incompatible with the old hardware needed to read the old media. The first few generations of PCs with holographic storage will likely still have SATA connections as well – not to mention a network connection
When I hear about your exploits to get rockbox working and syncing your music and setting up the myth box, they don’t sound easy to me. Yes it can be done and you might end up with something better, but it sure takes quite a bit of effort!
I like openness, but easy is also important; running a production quality Linux server is easier than running a windows one. Using Mac OS for your desktop is easier than using Windows or Linux. Using an iPod and iTunes is easier than an iAudio with Rockbox. Using my lame-ass “Foxtel IQ” PVR is easier and looks better than MythTV. (though with much crappier scheduling or library)
I was a bit surprised to hear you bought the Sonos systems (has been on my wish list for a long time, soon I’ll get it too); I expected you to buy a couple of cheap diskless mini Linux boxes and build your own!
I have all these grand plans for great solutions from home automation to video playback, but I’ll never have time for them. Until I retire, I’ll just have to buy what’s best in the market place…
And… There is also no guarantee that Rockbox and/or Ogg will play on hardware 10 years from now – you are effectively at the mercy of the hardware makers to make devices people can hack and run their own software on.
Nor is there any guarantee that 30 years from now there will be a C compiler at all for then current hardware and OS to compile Ogg/Vorbis or that anyone has had the stomach to port it to the newer technology. (people would have given up audio compression years ago)
You are effectively in the same boat as I am; you have to keep a close eye on when your chosen technology is no longer viable and migrate the data before it is too late. And I don’t think the chances of that happening are much smaller than using propriatery codecs or other software. And so long as the propriatary solutions allow you to extract your data in an efficient, scriptable way (all codecs currently do) you are just as future proof. Just don’t buy DRMed files.
You say that fading support for a codec is something you will easily notice, but that’s not necessarily the case if your vendor goes bankrupt overnight.
Assuming that doesn’t happen, the options open to you when dealing with the problem of support for a proprietary codec being dropped by your vendor are, according to you, either to not upgrade your hardware/software or to keep old hardware/software lying around, just in case you need it in the future.
Notable by its absence is the potential third option of using an alternative piece of software to take over job. This is possible when one does not use exclusive, proprietary technology from a single vendor.
You sacrificed this, the least painful migration path, when you invested heavily in proprietary technology. In doing so, your technological fate became intertwined with that of your single vendor. In my opinion, this is an undesirable state of affairs.
Moving on, the compatibility issues with the punch cards of yore were an early example of the perils of using proprietary technology. Once locked in, it was hard to get out.
The same principles that apply to software also apply to hardware: it’s bad to have a sole supplier for either, as it places a single point of failure in your supply chain.
This, as I see it, is the issue facing you today, namely that your vendor’s codec (or at least the co part of the codec) has no third-party support, because your supplier conducts business in a closed, exclusive manner. I see this as being distinctly at odds with the interests of you, the consumer.
I take your point regarding many open source/free software solutions not being as easy to configure and/or use as their proprietary equivalents, but there is no causal relationship between the two. Nothing dictates that free software must be harder to set up or use, any more than one has a guarantee that proprietary technology will work out of the box. Each is subject to the caprices of its makers.
A major advantage of using free software is that, whichever problem one encounters, it can be overcome. The same is not true of proprietary software, where you are at the mercy of the vendor, who may allow you to overcome your problem.
I also disagree with you on your statements about ease of use. In my own individual case, using Mac OS on my desktop would categorically not be easier than using Linux. I’ll spare you examples of why this is the case, as we’ve covered similar enough ground in the past that I assume you’ll just take my word for it.
Your statement may be true for a large number of users, but it is far from being applicable as a blanket statement. Similarly, there are plenty of Windows users who find Mac OS unintuitive and awkward, my wife included.
Similarly, using an iPod with iTunes is not necessarily easier than using an iAudio player with Rockbox. For example, in my own (real world) case, I need to be able to play music in Ogg Vorbis format, but an iPod with iTunes completely fails to perform the required task.
There’s nothing I can do to fix iTunes, but I can — thanks to open software — fix the iPod by putting Rockbox on it, so the question now becomes: Is it any easier to install Rockbox on the iPod than on the iAudio? In truth, I don’t think there’s much difference between the two.
Ease of use is a highly subjective concept. That’s why smart companies invest large amounts of money on UI testing and usability studies.
In that regard, I have no idea what to imagine when you say that your Foxtel PVR “looks better” and “is easier” than MythTV. These are subjective judgements that can not be empirically verified, other than by polling large numbers of people.
Even if I found myself in agreement with you that your PVR or its software is better looking than MythTV, I’ll personally choose functionality and efficacy over form every single time. MythTV may be tricky to set up, but that’s a one-time operation. Once done, no other PVR solution comes even close and I challenge even a beginner to have problems using it for recording and playback. Its UI is very well thought out and has been refined over time. Anyone who disagrees can choose from a number of alternative UI themes or even create their own by putting together a few XML files.
Like you, I value ease of use. I’m less concerned by ease of initial set-up, however, because that, by definition, is a one-time thing. Besides, it has been my career for many years to perform such work, so I’m well versed in it. That doesn’t mean I don’t get frustrated or gnash my teeth from time to time, but the set-up phase ultimately passes and I’m then free to enjoy superior results.
As for the Sonos, it was definitely a compromise on my part. I was prepared to make it, however, because the Sonos is, at least, elegantly modular: it doesn’t tie me to any particular brand of speaker or storage.
That leaves just the remote controllers and the zone controllers (amplifiers), of which I’m primarily interested in the former, as that’s where the UI and the software functionality reside. Open codecs are supported, which was an absolute requirement for me. Without those, the system would have been useless.
The system also comes with desktop controller software for Windows and Mac OS, but I don’t use either. Here again, if this had been a requirement of the system, I can once again say that I would not have purchased it.
Although the Sonos system is proprietary, a lot can be achieved with it using UPnP. This opens the door to third-party software to drive the system and is a welcome benefit. It gives a semblance of openness to an otherwise closed system.
Of course, I’d be happiest if either Sonos opened up the system or a project was started to develop alternative firmware for the remote controller. Indeed, I hope the latter may happen one day.
The reason I didn’t choose Linux boxes for the task was the difficulty associated with producing a small, hand-held remote control unit with LCD screen to manage the system. I also knew of no free or open software that could link listening zones.
Using MythMusic was an option, but a requirement was that it should not be necessary to turn on a TV to drive the system. I could have overcome this with an LED or a VFD display, but as I mentioned above, I would still not have been able to link zones, another absolute requirement for our home.
Sonos was, therefore, a somewhat reluctant compromise, although I did like enough about the system to still be very excited about installing it. So far, I haven’t regretted my purchase, although I would definitely prefer an open alternative (and one that didn’t try so hard to mimic the appearance of Apple’s product line, which is not to my taste).
Next, you claim there’s no guarantee that Rockbox or Ogg Vorbis will play on hardware ten years from now. It’s true that the Rockbox project may have fallen by the wayside by that point, but as long as there’s a working C compiler for a given architecture and a way to load and execute the compiled object code on the hardware, it will remain possible to play Ogg Vorbis format files on that architecture.
You can say that this requires hardware manufacturers to continue to make devices that are flexible enough to be loaded with alternative firmware, but the market for such devices is currently healthy enough that I have few worries on this score. Heck, even Apple allows you to dispense with its iPod firmware in favour of something better, which is something of an unlocked door in their otherwise high-security prison-like environment.
To say there is no guarantee that, 30 years from now, there will be a C compiler available for a given architecture is, IMHO, clutching at straws. There’s no guarantee there will be an inhabitable world, either. In fact, there are no guarantees whatsoever regarding the future.
Aside from the fact that the importance of C as a high-level assembly language currently shows no signs of lessening, the present day legacy of C is large enough that people will need to be able to compile C on whichever architectures are current for many decades to come. Analogously, why do you think there are COBOL compilers available today for x86?
Personally, I feel it’s more pertinent to look less far into the future. Whereas you may argue that I can have no guarantee of support for Ogg Vorbis some 30 years from now, I would contend that you have no guarantee of support for ALAC this time next year, because you have a single point of failure in your software supply chain.
If you truly believe that the chance of a proprietary codec or other piece of proprietary software becoming obsolete is not significantly higher than in the case of an open standard, system or protocol, then you are not only deluding yourself, but also failing to observe history. The path of computing is littered with discarded proprietary software, not all of which had outlived its usefulness.
Just look at which protocols, languages, systems, applications, standards and algorithms have survived the last few decades. Then look at the ratio of proprietary inventions to those based on open standards. What do you see?
If the vendor goes bankrupt overnight, their software doesn’t stop working!
Yes the chance might be higer of becoming obsolete, but that doesn’t mean moving on has to be any harder that with FOSS so long as your choice was something that has a documented extraction API; like I said, the existing software won’t just stop working.
I agree with your point in general; if you leave something proprietary lying around for 10 years and then you’ll get into trouble. But my music is something I use every day – I’d certainly notice if the iPod, iTunes or just the ALAC coded got discontinued before it is too late.
What I don’t understand is why the smaller music player makers (iAudio and the likes) don’t simply stop making their own sucky software and just use Rockbox. Maybe even start an FOSS “RockTunes” that works well on the 3 major platforms. They then could finally compete properly with iPod/iTunes to the masses and focus on what they do best: make hardware and let the comunity take care of the rest.
Or why people like Pace (My Foxtel IQ and Sky+), Samsung and other crap DVR makers just base what they release on MythTV. The quality of the software would be so much better and people’s experience would be better – and they would recommend the product to so many more people. It really bugs me they spend that much time (and money!) on developing their own software from scratch and it is still just crap.
It doesn’t make business sense to me. At all.
That said: I don’t see what I have to gain from putting Rockbox on my iPod; ReplayGain and CrosMix would be nice, but not at the cost of battery life – Rockbox would halve the battery time (software decoding!?)
If you discard the setup phase, yes, Myth is likely just as easy to use as my Foxtel box. But when I say it looks better, I mean the image quality; it just stores the MPEG streams – something MythTV can only do in limitted cases. (if you are fortunate to have a good selection of DVB-T channels, like FreeView, or a decryptable cable provider.
If your vendor goes bankrupt, their software doesn’t just stop working, no, but you do find yourself at the end of an evolutionary cul-de-sac unless someone else picks up the rights.
I, too, think it would be a smart decision for companies like iAudio to invest more of their development resources in a project like Rockbox than to develop their own firmware from scratch.
Actually, their own software isn’t even that bad, but why reinvent the wheel? Perhaps they feel that their firmware is what differentiates their products from the rest of the market and that players would become indistinguishable if they all ran the same firmware. I don’t know, so I’m just guessing.
If I remember correctly, their firmware has some patented spatial sound algorithm stuff, but I can’t remember its name. I don’t think I’ve ever played an entire song using the original firmware.
Whatever their reasons, it would be a lot cheaper for them to refine and use Rockbox than to develop their own firmware. They might have to make a few tweaks to the UI to make it as user-friendly as they’d like it to be, but apart from that, the work has mostly been done. The same applies to the manufacturers of all other currently popular personal jukeboxes.
As for putting Rockbox on the iPod, I had understood that the battery life was better with Rockbox. Is that not the case?
You’d also get some other codec support, which is probably useless to you, since you use ALAC. Apart from that, there are plug-ins, the UI is completely user-definable (with themes, icons, fonts, etc.), you can have spoken menus, there are simple patches to display album art, plus lots of other nice settings to play with.
Regarding MythTV, whether or not it can store MPEG streams directly to disc depends entirely on the hardware you put inside the machine. It has nothing to do with MythTV per se, which is really just the UI and scheduling logic. DVB-C, -T and -S cards work fine, as long as there’s a Linux driver for the hardware.
Similarly, your Foxtel box wouldn’t be able to do much with my cable provider’s Nagravision 2 encryption. There’s simply no sane way around it.
The RockBox buyers guide lists battery life as 8 hours. Apple lists it as 14, though I don’t know what the actual playback time is. (it feels more than 8 for sure)
Of course it is not MythTV’s fault, it supports the DVB receivers which in turn would have to support the encrypting. But you can’t blame me for looking at the system as a whole to judge wether it would suit me!
But so far few people seem to have much luck with anything other than Irdeto. Foxtel here in Oz use “NDS Videoguard”, for which CAMs aren’t even available. (And likely never will be)
I know that Apple has had a lot of trouble with iPod batteries failing to meet the claims that Apple has made about them. Perhaps the Rockbox claim of 8 hours is taking that into consideration.
It does, indeed, seem that iPod power management is still immature. There’s a Rockbox page with the full lowdown. Power management for other architectures (e.g. iRiver) has now surpassed the original firmware, which is an achievement that speaks for itself.
I definitely don’t blame you for looking at systems as a whole when considering whether they’re suitable for your needs. That’s really the only practical way to judge a system.
As they say: meten is weten, so I put it to the test. As it turns out, the iPod is quite bad at playing ALAC files. I can only presume that, like RockBox, it doesn’t make use of a hardware decoder to do it and therefor suffers just as much. 7 hours is all I could get out of it and that is what people quote around the internet in general. RockBox also quotes 7 hours for playing back FLAC files.
Playing my older 256K MP3s, however, I managed to get 13 hours out of it, which is a lot more than RockBox does. (they say 8 hours for low-bitrate MP3) As smaller files tend to take less processing and less disk reads, it wouldn’t surprise me that with the low bitrate files Apple and RockBox use for their endurance testing, it wouldn’t surprise me if it did make the quoted 14 hours.