Ugh no, and if you do, you deserve the shitty quality you're getting. You're lucky to get even 128 kbit/sec through youtube if at all, and anyone with decent ears can pick out the shitty metallic drum sound that comes along with such low bitrates.
Maybe I should be more blunt - can someone fix the spelling mistake in the title please? Spell checkers really aren't that hard to use. I'm pretty sure Geoengineering does not have a Furture.
(Argh, I just lost a 20-paragraph post because I chose to change my post style to plain old text so it would format nicely. Thanks slashdot...)
I'll be brief this time. Disclaimer: I'm the author of morituri, a CD ripper for Linux with support for AccurateRip, modelled after Exact Audio Copy but command line.
I was in the same situation as you a few years ago. I had originally ripped my collection to Ogg/Vorbis, and thought that this time I wanted everything 100% lossless so I would never have to rip again, but just transcode from the rips. The main issue I wanted to solve, besides going lossless, is to make sure I had no bad tracks with skips in my collection. (You detect those skips over the years listening to the songs, not as you do the rip, and you're never sure if there are glitches in the tracks or not, and it drove me crazy).
But when I researched what it meant to get it right this time, my mind got blown at everything that could go wrong. Here's a condensed version of the results of my research.
The biggest eye opener to me was that the fact that each drive model reads samples with a different offset. That offset is always the same for that model, but different across models. I have no idea why it is so (does anyone know), and we're lucky that it's constant for a model, otherwise I wouldn't even be able to solve my main concern - the detection of skips and bad rips. Nowadays people use AccurateRip, a database of checksums for ripped tracks that people upload. If your rip matches several other people's rips, you can be reasonably sure that you have a correct rip.
Since at the time there wasn't a single Linux-based ripper doing this, I created morituri.
There are several other issues that make ripping a fragile activity. I recommend you get a drive that is able to rip Hidden Track One Audio (The audio in Track 01 but between Index 00 and 01). Maybe you don't care, but I have a few gems in my collection with good stuff there (two Soulwax albums and Luke Haines's Das Capital spring to mind). Some drives are simply not able to get at this data. Most software doesn't get it either. EAC can be told to do so, but it's a manual and fragile process. morituri's goal is to create a perfect image so that you can burn a bit-exact copy; so it rips the HTOA tracks always.
I suggest you rethink whether you really want to go quick and dirty. You're going to rip the cd's once and then listen to the result many times. Are you sure you don't want to get it right on the first try this time ? Is your time spent changing the discs not valuable enough to not have to repeat it ?
morituri is probably slower than less accurate rippers, as the focus is accuracy. I would argue that the time spent ripping and encoding really is not the biggest issue. The real trouble is having to change disks, which is going to take time no matter how much time it takes for your computer to do its thing.
I made a quick calculation of how much time I would be spending to put in my 1600 CD's, and decided to spend that time on creating a LEGO CD changer instead (I had checked the price of disc changers, and the cheapest I could find was around $800, with no real guarantee of whether I'd be able to control it from Linux).
Friends visiting shared their scorn and admiration in equal doses, but the robot was able to do around 20 CD's reliably in one go, so I would just load them up in the morning before work. 3 months later my 1600 CD collection was digitized.
morituri interfaces with MusicBrainz to get the metadata, and you can retag albums later on based on a different release id or when the data is updated on MB. There's also options to do an encode of lossless rips; I regularly run a simple shell command to transcode the flacs to mp3s, and it only transcodes what wasn't done before.
I'm the author of morituri, which is a CD ripper for Linux which uses AccurateRip. I was not aware of any restrictions wrt. GPL - can you point me to something with more information so I can figure out what the deal is and whether I should change anything?
There were always be complainers...
The title clearly says 'for geeks'. If you are unable to install a newer version of Firefox, Chrome, or Opera, then clearly you are not a geek and hence this presentation is not for you.
There's more to opensource than the GPL. If this project chose the GPL, then it chose the wrong license - the GPL has a very specific patent clause. The project should have gone with a BSD or LGPL or similar license. In this case, they could team up with any of the distributors that are shipping linux and have the money and incentive to ship this application and pay the licensing fee for their users - if the application is good enough. It
GStreamer is under less of a threat than others
on
VLC & European Patents
·
· Score: 5, Interesting
I am one of the GStreamer developers. I'm flattered we are in this list, but we don't really belong there. GStreamer is under much less of a threat than the other projects mentioned here.
Why ? Because GStreamer was designed *from the start* to be pluggable. The whole patent issue is one of the main reasons why GStreamer is designed the way it is. Sure, it took a lot longer to get to a point where stuff starts to Just Work, because we wanted to make sure we would be around when the shit hits the fan.
So while a lot of other projects chose to ignore the whole patent problem, and a lot of projects used the GPL as a license (which indeed is not compatible with patents), making it possible for any distro to ship them, we had the focus of making sure that the GStreamer platform is pluggable to the point where the libraries can be put in or taken out without breaking the applications. It's also one of the reasons why GStreamer, from the start, has been LGPL - because that allows distributors to ship a complete stack of GStreamer applications legally in places where software patents apply (like, say, the whole US). Fighting software patents is a great idea. Waving the problem away as if it's not there is not.
Also, with the arrival of Fluendo, a company building stuff on top of GStreamer, (and also a company I happily work for:)), people will be able to get codecs for the patented formats in a legal way, if they chose not to run the risk, or if they want to be legally safe.
What does this mean in the end ?
Distributions can finally ship a multimedia platform in a legal way; see the up-take on Totem and RhythmBox for example. Flumotion, Fluendo's streaming server with support for royalty-free codecs, is a new project and already it is gaining quite an uptake.
Very few distros have taken the risk to ship one of the other projects, for legal reasons. (Apparently the mighty Debian ships Xine, and while on any other non-free subject lots of noise is made, this one seems to be left alone because it's a big deal).
It is no coincidence that projects like mplayer, vlc, and xine do not get shipped by most distributions. In fact, coincidentally, Fluendo did a press release on this very issue yesterday.
Source does not have to be "crippled" to be shippable. Other projects get their tarball mangled to remove all questionable code, causing lots of bug reports,... Take XMMS in Fedora as an example - people complained loudly about the removal of MP3. Actually, Red Hat had the guts to make a stand and decide "we can't legally ship this, and we should stop pretending it's not a problem."
GStreamer had some discussions with the FSF (here's the result. In a nutshell, it is vital for a complete framework (ie, all parts of its stack) to not be GPL (or GPL, with an exception clause for GStreamer - see our licensing advisory for more info). The GPL is not compatible with patents. A distro can not risk shipping a stack of libs/plugins/applications where one of these is GPL.
"For sale" distributions will finally be able to ship proprietary plugins for these patented codecs, as well as playback applications, and DVD playback, *and it will finally be legal* on Linux.
Apart from Sorenson (who outright refuse - or are not allowed - to license code to anyone but Apple), codec companies are turning around, taking note of Linux, and Fluendo is stepping up to make sure that those who really want these proprietary codecs can buy them.
Here is what you can do. People need to realize that, jus
I had tried VLC myself as the first player on Win32 while working on the server. I've asked for information on what could be wrong, because except for not starting on a keyframe in the stream the streams are perfectly fine. Even not starting on a keyframe is something a player should be able to handle.
Unfortunately time was limited and we cannot test every player when we're getting ready for our first public test. I'm sure that after this conference we can work together with the VLC people to make the streams work.
Having said that, not putting VLC on the page was an oversight on the part of the person that put up the webpage, and we added it.
No reason to release it ? I'm guessing you don't work on open source software.
There's no point in releasing software that's in the process of being designed. We're better off making it possible for people to contribute by having decided on a stable base ourselves first before we release it. That's how *every* open source project got started.
Imagine Linus releasing his code after the first time it booted - it would really have sucked for him to have to reply to a slew of mails on "well it boots, but that's about it. What next ?"
Obviously, we are going to release it. All of us are long-time contributors to free software. But nothing says that we are forced to release it as soon as we have int main(int argc, char *argv[]) { exit(0);} written.
Because you have your facts wrong ? The only thing that is open source about Helix is a) the player and b) part of the framework, including only some of the Ogg codecs.
The producer is completely proprietary, so there's no way you can do any open source streaming with Helix as the framework. It's quite obviously not part of their business model. The only reason parts of Helix are being GPL'd is exactly to court the businesses involved in open source.
Translated: their marketing guys finally thought it was a good idea if they want to sell music to you, the customer.
Woohoo, Xiph !
Anyways, we have a Theora live webcam stream for you guys to test out. AFAIK we're the first doing this.
http://mirror.fluendo.com:8801/
With MPlayer, for example, you'd do mplayer -cache 40 http://mirror.fluendo.com:8801 to watch it.
If you're lucky you can catch Rupert coding. Not a lot goes on in this stream, we're fairly boring (Read: our boss is watching too)
We'll be adding Vorbis sound sometime this week too. The server will be Coming Soon to a Repository Near You.
With your spelling capacity, it probably was because you typed "rm hte box *.mp3"
Anyways, your statement is crap, RhythmBox doesn't write to mp3 files, so it can't hose them.
sigh, if I had known you people would be actually reading on New Year's eve... you're supposed to be out partying like me damnit !
Anyway, if anyone wants to set me up with an ftp or scp account so I can upload the iso's, let me know ! thomas (at) apestaart (dot) org, I can start uploading right away.
Bowie, you completely certified crackpot (don't have time to post all of the insulting program-my-coloured-balls-ideas mails you sent), the fact that you EVER put "Red Hat contributor" on your resume would probably be grounds for a trial with you on the receiving end.
So what the hell are you complaining about ? It's not any less legal to keep putting "Red Hat contributor" on your resume than it was before. If you are moaning about how in your delusional world the move to Fedora makes that claim somehow less valid then shut up:) No actual developer is going to care at all about your rants if your resume is the reason you're against this move.
Personally I don't think the XBox is the way to go. Sure, it is readily available. Sure, it is cheap. Sure, Microsoft is selling them at HUGE loss.
But I really don't want to be limited by the limited hardware. In two years' time, how are you going to upgrade the box ?
I'm working on a similar project myself (A href="http://davedina.apestaart.org/">The Dave/Dina Project), which is a distribution (based on Red Hat) to turn a PC into a media hub. It works, it's in our living room, it has 200 GB of storage space (the 550 albums it has encoded to Ogg to date take about 35 GB of those), it
records video (we record about 15 shows each week, all through a web interface), it plays emulator games and even Doom, it shows photos, and s on.
It isn't the prettiest thing in the world (WE NEED ARTISTS !), but it's open, you can swap out components, tinker with it, and help us improve it.
I don't want to be tied to any hardware at all, especially not Microsoft's. How long before a cease-and-desist order is issued ?
Well, I know that "ease of download" is the reason given for incorporating libraries. I think that is just plain invalid any way you look at it.
First of all, people who don't want to spend half their life downloading and installing stuff use a distribution. I know, I do so too. If you are suffering from "dependency hell" you should use a distribution. Red Hat was the classic problem distribution here, and tools like red-carpet, up2date, or apt for rpm solve these. It's up to distributions and packagers to make good packages of dependencies. The time spent there is a lot more useful for the community than time spent taking libs apart.
I know very well what I'm talking about, since I package GStreamer, a project that is able to use more than thirty outside libraries. I have built packages for a lot of those libraries that play nicely with Red Hat. It is possible.
Cinelerra doesn't live in a vacuum, and the libs they incorporate are very common in thesse kinds of apps. If every application were to include it's own version of all of these libraries, the economic advantage is quickly wasted. The least that could be done is to at least allow for outside libraries to override the included ones.
Saying that the code is GPL is very true but shows precisely the problem with open source - just because you CAN copy and rework other people's code doesn't mean that's a good idea ! In this case, it isn't - reuse other people's code and improve the library you're using instead of forcing people to lock into your own version of it.
If the cinelerra developers were really worried about their users' installation experience, they wouldn't be suggesting that people run rpm --nodeps --force to install software. That's just silly and shows you don't know enough about packaging and software reuse.
It is good that applications like these are making their way to Linux. However, some things are really bad about Cinelerra and it's developer and it's important that they're noted so that the community can try to resolve these.
ANY application developer that serves RPM's on their homepage and recommend you to "install them by using rpm --force --nodeps" really shouldn't make RPM's AT ALL. There is nothing worse than telling users of your software to mess up their packaging system. If the answer to this is "well that's because RPM sucks", then you don't know what you're talking about. It's perfectly possible to make good RPM's. In fact, if prodded, I'll make them from cinelerra to prove my point.
A really bad issue in Cinelerra is how it incorporates every outside library inside it's source tree instead of using external libraries. We all need to promote code reuse. Taking other people's code and putting it in your tree is bad for several reasons : you're bloating your software when you should be reusing libraries; fixes to those libraries do not go back upstream to the original library and thus the community isn't advancing. There aren't enough advantages to "stealing" code like this to warrant it. Please force the author to reuse software properly and play nice with the rest of the community.
Broadcast 2000 got pulled from the site due to "copyright problems" or "disillusion with the community on HeroineWarrior's side" (depending on who you ask). So what has changed about that now to ensure this won't happen to Cinelerra ?
I'm certainly going to try the final release, and HeroineWarrior knows what he's doing and has the advantage of actually having produced usable apps.
But, in my opinion, applications like this are a nice transition but ultimately a dead end for the community. No one benefits much from applications like these. We should stick to what makes open source as good as it is : code reuse, polishing, cooperation.
Slashdot Mirror
Ugh no, and if you do, you deserve the shitty quality you're getting. You're lucky to get even 128 kbit/sec through youtube if at all, and anyone with decent ears can pick out the shitty metallic drum sound that comes along with such low bitrates.
Interesting, a user moderated this off-topic.
Maybe I should be more blunt - can someone fix the spelling mistake in the title please? Spell checkers really aren't that hard to use. I'm pretty sure Geoengineering does not have a Furture.
Did he talk about it furtively because he knew he didn't spellcheck first?
(Argh, I just lost a 20-paragraph post because I chose to change my post style to plain old text so it would format nicely. Thanks slashdot...)
I'll be brief this time. Disclaimer: I'm the author of morituri, a CD ripper for Linux with support for AccurateRip, modelled after Exact Audio Copy but command line.
I was in the same situation as you a few years ago. I had originally ripped my collection to Ogg/Vorbis, and thought that this time I wanted everything 100% lossless so I would never have to rip again, but just transcode from the rips. The main issue I wanted to solve, besides going lossless, is to make sure I had no bad tracks with skips in my collection. (You detect those skips over the years listening to the songs, not as you do the rip, and you're never sure if there are glitches in the tracks or not, and it drove me crazy).
But when I researched what it meant to get it right this time, my mind got blown at everything that could go wrong. Here's a condensed version of the results of my research.
The biggest eye opener to me was that the fact that each drive model reads samples with a different offset. That offset is always the same for that model, but different across models. I have no idea why it is so (does anyone know), and we're lucky that it's constant for a model, otherwise I wouldn't even be able to solve my main concern - the detection of skips and bad rips. Nowadays people use AccurateRip, a database of checksums for ripped tracks that people upload. If your rip matches several other people's rips, you can be reasonably sure that you have a correct rip.
Since at the time there wasn't a single Linux-based ripper doing this, I created morituri.
There are several other issues that make ripping a fragile activity. I recommend you get a drive that is able to rip Hidden Track One Audio (The audio in Track 01 but between Index 00 and 01). Maybe you don't care, but I have a few gems in my collection with good stuff there (two Soulwax albums and Luke Haines's Das Capital spring to mind). Some drives are simply not able to get at this data. Most software doesn't get it either. EAC can be told to do so, but it's a manual and fragile process. morituri's goal is to create a perfect image so that you can burn a bit-exact copy; so it rips the HTOA tracks always.
I suggest you rethink whether you really want to go quick and dirty. You're going to rip the cd's once and then listen to the result many times. Are you sure you don't want to get it right on the first try this time ? Is your time spent changing the discs not valuable enough to not have to repeat it ?
morituri is probably slower than less accurate rippers, as the focus is accuracy. I would argue that the time spent ripping and encoding really is not the biggest issue. The real trouble is having to change disks, which is going to take time no matter how much time it takes for your computer to do its thing.
I made a quick calculation of how much time I would be spending to put in my 1600 CD's, and decided to spend that time on creating a LEGO CD changer instead (I had checked the price of disc changers, and the cheapest I could find was around $800, with no real guarantee of whether I'd be able to control it from Linux).
Friends visiting shared their scorn and admiration in equal doses, but the robot was able to do around 20 CD's reliably in one go, so I would just load them up in the morning before work. 3 months later my 1600 CD collection was digitized.
morituri interfaces with MusicBrainz to get the metadata, and you can retag albums later on based on a different release id or when the data is updated on MB. There's also options to do an encode of lossless rips; I regularly run a simple shell command to transcode the flacs to mp3s, and it only transcodes what wasn't done before.
Give it a try, let me know what you think.
I'm the author of morituri, which is a CD ripper for Linux which uses AccurateRip. I was not aware of any restrictions wrt. GPL - can you point me to something with more information so I can figure out what the deal is and whether I should change anything?
I'm sorry, but if IPv6 addresses are going pubic as you say, I'm going to be a eunuch.
There were always be complainers... The title clearly says 'for geeks'. If you are unable to install a newer version of Firefox, Chrome, or Opera, then clearly you are not a geek and hence this presentation is not for you.
There's more to opensource than the GPL. If this project chose the GPL, then it chose the wrong license - the GPL has a very specific patent clause. The project should have gone with a BSD or LGPL or similar license. In this case, they could team up with any of the distributors that are shipping linux and have the money and incentive to ship this application and pay the licensing fee for their users - if the application is good enough. It
Why ? Because GStreamer was designed *from the start* to be pluggable. The whole patent issue is one of the main reasons why GStreamer is designed the way it is. Sure, it took a lot longer to get to a point where stuff starts to Just Work, because we wanted to make sure we would be around when the shit hits the fan.
So while a lot of other projects chose to ignore the whole patent problem, and a lot of projects used the GPL as a license (which indeed is not compatible with patents), making it possible for any distro to ship them, we had the focus of making sure that the GStreamer platform is pluggable to the point where the libraries can be put in or taken out without breaking the applications. It's also one of the reasons why GStreamer, from the start, has been LGPL - because that allows distributors to ship a complete stack of GStreamer applications legally in places where software patents apply (like, say, the whole US). Fighting software patents is a great idea. Waving the problem away as if it's not there is not.
Also, with the arrival of Fluendo, a company building stuff on top of GStreamer, (and also a company I happily work for :)), people will be able to get codecs for the patented formats in a legal way, if they chose not to run the risk, or if they want to be legally safe.
What does this mean in the end ?
Very few distros have taken the risk to ship one of the other projects, for legal reasons. (Apparently the mighty Debian ships Xine, and while on any other non-free subject lots of noise is made, this one seems to be left alone because it's a big deal).
It is no coincidence that projects like mplayer, vlc, and xine do not get shipped by most distributions. In fact, coincidentally, Fluendo did a press release on this very issue yesterday.
Unfortunately time was limited and we cannot test every player when we're getting ready for our first public test. I'm sure that after this conference we can work together with the VLC people to make the streams work.
Having said that, not putting VLC on the page was an oversight on the part of the person that put up the webpage, and we added it.
No reason to release it ? I'm guessing you don't work on open source software. There's no point in releasing software that's in the process of being designed. We're better off making it possible for people to contribute by having decided on a stable base ourselves first before we release it. That's how *every* open source project got started. Imagine Linus releasing his code after the first time it booted - it would really have sucked for him to have to reply to a slew of mails on "well it boots, but that's about it. What next ?" Obviously, we are going to release it. All of us are long-time contributors to free software. But nothing says that we are forced to release it as soon as we have int main(int argc, char *argv[]) { exit(0);} written.
Because you have your facts wrong ? The only thing that is open source about Helix is a) the player and b) part of the framework, including only some of the Ogg codecs. The producer is completely proprietary, so there's no way you can do any open source streaming with Helix as the framework. It's quite obviously not part of their business model. The only reason parts of Helix are being GPL'd is exactly to court the businesses involved in open source. Translated: their marketing guys finally thought it was a good idea if they want to sell music to you, the customer.
Woohoo, Xiph ! Anyways, we have a Theora live webcam stream for you guys to test out. AFAIK we're the first doing this. http://mirror.fluendo.com:8801/ With MPlayer, for example, you'd do mplayer -cache 40 http://mirror.fluendo.com:8801 to watch it. If you're lucky you can catch Rupert coding. Not a lot goes on in this stream, we're fairly boring (Read: our boss is watching too) We'll be adding Vorbis sound sometime this week too. The server will be Coming Soon to a Repository Near You.
With your spelling capacity, it probably was because you typed "rm hte box *.mp3" Anyways, your statement is crap, RhythmBox doesn't write to mp3 files, so it can't hose them.
anyway, a first mirror is up at http://zandbak.zoo.apestaart.org/davedina-0.0/
sigh, if I had known you people would be actually reading on New Year's eve... you're supposed to be out partying like me damnit ! Anyway, if anyone wants to set me up with an ftp or scp account so I can upload the iso's, let me know ! thomas (at) apestaart (dot) org, I can start uploading right away.
Bowie, you completely certified crackpot (don't have time to post all of the insulting program-my-coloured-balls-ideas mails you sent), the fact that you EVER put "Red Hat contributor" on your resume would probably be grounds for a trial with you on the receiving end.
:) No actual developer is going to care at all about your rants if your resume is the reason you're against this move.
So what the hell are you complaining about ? It's not any less legal to keep putting "Red Hat contributor" on your resume than it was before. If you are moaning about how in your delusional world the move to Fedora makes that claim somehow less valid then shut up
keep twatting about !
But I really don't want to be limited by the limited hardware. In two years' time, how are you going to upgrade the box ?
I'm working on a similar project myself (A href="http://davedina.apestaart.org/">The Dave/Dina Project), which is a distribution (based on Red Hat) to turn a PC into a media hub. It works, it's in our living room, it has 200 GB of storage space (the 550 albums it has encoded to Ogg to date take about 35 GB of those), it records video (we record about 15 shows each week, all through a web interface), it plays emulator games and even Doom, it shows photos, and s on.
It isn't the prettiest thing in the world (WE NEED ARTISTS !), but it's open, you can swap out components, tinker with it, and help us improve it.
I don't want to be tied to any hardware at all, especially not Microsoft's. How long before a cease-and-desist order is issued ?
I know very well what I'm talking about, since I package GStreamer, a project that is able to use more than thirty outside libraries. I have built packages for a lot of those libraries that play nicely with Red Hat. It is possible.
Cinelerra doesn't live in a vacuum, and the libs they incorporate are very common in thesse kinds of apps. If every application were to include it's own version of all of these libraries, the economic advantage is quickly wasted. The least that could be done is to at least allow for outside libraries to override the included ones.
Saying that the code is GPL is very true but shows precisely the problem with open source - just because you CAN copy and rework other people's code doesn't mean that's a good idea ! In this case, it isn't - reuse other people's code and improve the library you're using instead of forcing people to lock into your own version of it.
If the cinelerra developers were really worried about their users' installation experience, they wouldn't be suggesting that people run rpm --nodeps --force to install software. That's just silly and shows you don't know enough about packaging and software reuse.
- ANY application developer that serves RPM's on their homepage and recommend you to "install them by using rpm --force --nodeps" really shouldn't make RPM's AT ALL. There is nothing worse than telling users of your software to mess up their packaging system. If the answer to this is "well that's because RPM sucks", then you don't know what you're talking about. It's perfectly possible to make good RPM's. In fact, if prodded, I'll make them from cinelerra to prove my point.
-
A really bad issue in Cinelerra is how it incorporates every outside library inside it's source tree instead of using external libraries. We all need to promote code reuse. Taking other people's code and putting it in your tree is bad for several reasons : you're bloating your software when you should be reusing libraries; fixes to those libraries do not go back upstream to the original library and thus the community isn't advancing. There aren't enough advantages to "stealing" code like this to warrant it. Please force the author to reuse software properly and play nice with the rest of the community.
- Broadcast 2000 got pulled from the site due to "copyright problems" or "disillusion with the community on HeroineWarrior's side" (depending on who you ask). So what has changed about that now to ensure this won't happen to Cinelerra ?
I'm certainly going to try the final release, and HeroineWarrior knows what he's doing and has the advantage of actually having produced usable apps. But, in my opinion, applications like this are a nice transition but ultimately a dead end for the community. No one benefits much from applications like these. We should stick to what makes open source as good as it is : code reuse, polishing, cooperation.