"the [CRF-created] file would set up a process that automatically delivers files in the right format and potentially triggers an automatic payment system that could be changed moment to moment by the content distributor."
Yeah, because, you know, that's just what consumers want.
Still, there are some holes in Revolutions that are pretty gaping. I think they got pressure from the studios that it was too long, or to make a marketing gimmick out of it like so: 1) cut out the philosophical stuff, leave all of the formulaic rah-rah machine/zion battle (notice a lot of other scenes that feel like they just end too quickly, like when Neo gets to cry for like 2 seconds when Trinity dies; 2) give it all back in the super-extended-directors-cut-special-edition DVD, which will probably come out after everyone's bought the regular-super-special-edition of the trilogy. Everybody (almost) wins.
What would happen if a real election went through where these things were used, then after the fact it was discovered that there was tampering? I guess it's too much to expect to have a punch-card backup plan.
The majority of my music listening time is spent between work and my commute. Listening to Ogg Vorbis files at work is easy, but once Kenwood (or another equally good car stereo manufacturer) gets on the Ogg bandwagon, I'll be more than happy to re-encode all my CDs to Ogg instead of MP3. Until I have a car CD player, I can't switch.
Kenwood makes the MusicKeg, a rebranded Phatbox, which plays FLAC and I believe you can get firmware from PhatNoise to play Vorbis also. They are still working on optimizations to Tremor to play the highest quality levels smoothly.
You have to assume a lot of risk to "work the system". I don't know what state you live in, here's just one of many examples that can hose your plan B:
1. you rear-end some guy in your car because someone rear-ended you
2. the guy you rear ended is an executive and you do some "serious" physical damage to him
3. he talks to his lawyer, who finds out how much insurance you've got and how much equity there is in your house, and whatever else you "own"
4. they sue you for 2x that; you settle for 1x or maybe lose the case
Talk to a lawyer or insurance broker about this. If the've been doing it a while they're sure to have lots of stories for you.
What surprised me though was how much faster Monkeys compressed in comparison to FLAC...with monkeys having slightly smaller files no less.
People bring this up all the time but it never seems to occur to them that you encode only once but decode many times, and as long as encoding is at least as fast as ripping, the encoding speed doesn't really matter.
So what's left is the few % difference in file size. For that you get a slew of features that are much more useful to a user (unless you plan to only ever listen to your music on a Windows box). The FLAC features page spells these out.
Because how many portable and/or home stereo components play FLAC? I'd venture a guess of: none.
Well, no, it's more than "none". There is a list of hardware devices that support FLAC on the homepage. And there are a few more in the works. The C reference codec and low decode complexity make it relatively simple to add FLAC support to devices.
Couldn't they mandate a particular IEEE rounding mode to get deterministic behavior for a 100% lossless reconstruction? Isn't there an integer codec for vorbis now?
Sorry, I should have said "libvorbis decodes to float samples" (I believe). But the basic problem remains, that in order to make the FLAC+Vorbis thing work would require standardizing the representation of decoded samples which is not practical and doesn't really have any advantages outside this particular untried idea.
Does anyone know if there is any way to edit FLAC files at the commandline? Like tell it to output a region from a starting time to an ending time to another file?
Kind of. The command-line decoder has switches --skip and --until to decode a specific section, which you could pipe back into the encoder again.
It's possible to make a tool like vorbiscut that will split on frame boundaries.
One idea that would be really cool is if they could get acheive lossless compression by noting the differences between the original and the.OGG, and appending that to the.OGG. Then if you can just strip off the added info when you make copies to restricted-space devices. The only question is whether this can be done with a competitive compression ratio.
This has been suggested before, but would require all Vorbis decoders to decode to the exact same result, which is not practical (Vorbis decodes to float samples).
It would be a serious feat to integrate FLAC and OGG. They are totally different systems.
Not so, they are already integrated, i.e. you can already encode to raw FLAC or Ogg FLAC with the command-line flac encoder. FLAC packets are embeddable in an Ogg container just as easily as Vorbis ones.
This is good news in a nebulous sense, but what about actually getting 3rd party adoption? How many players out there support FLAC?
There's a list on the sidebar of the FLAC homepage.
I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support?
In the case of the AudioTron, they are getting the full court press from Microsoft to do WMA lossless, and knowing Microsoft this will be to the exclusion of all others. I made a good case on their mailing list that with moderate work (and I was willing to help), the AT would be able to decode FLAC natively. Their response has always been "we tried it and it's not fast enough", despite the fact that identical hardware in other devices (Rio Receiver, PhatBox) can decode FLAC fine.
But no matter, other manufacturers are providing a choice, and the list is growing. Recently the ReQuest guys have added FLAC support to their ARQ boxes. So time will tell what consumers really want.
The FLAC format has metadata support, and since you now can put FLAC in Ogg containers, it can also use Ogg tag support which is truly great.
Minor point, but the tags are not part of the Ogg container. FLAC implements tags the same way as Vorbis does, as one of the initial packets, so they are available in raw FLAC as well as Ogg FLAC.
Let's see, at [pulls # out of ass] 10 cents a minute, that's 190,000 compute-years just to break even! OK, so maybe they will be able to charge more but they must be planning on a pretty sizable market. Or recoup rendering Toy Story sequels.
I think they were using a fixed-point implementation (see here [comms.net]). Maybe (probably) Tremor is a more optimal implementation. I suspect we'll find out soon enough.
Wow, didn't realize how soon; the PhatBox guys have
already tried it.
I ask because people have played with an earlier floating point implementation on the Rio Receiver, and have found that it wasn't terribly usable. I'm a little short on details, but I think it was too intensive for the low-speed CPU in the receiver.
I think they were using a fixed-point implementation (see here). Maybe (probably) Tremor is a more optimal implementation. I suspect we'll find out soon enough.
The chip used in the Rio Receiver I believe is pretty common in other designs (PhatBox, Empeg/Rio Car, AudioTron) and seems like it's becoming the de facto measuring stick for whether or not a codec will run in consumer hardware.
On the other hand, there has been work to build replacement clients for the Rio Receiver that use FLAC lossless compression, and that apparently works pretty well. So the current thinking is to transcode.ogg to flac at the server level. Or just to rip everything to flac (which requires a whole lot more disk space.:( )
FLAC adoption happened relatively fast after a free integer decoder library was available (though it is LGPL, not BSD, which has caused some hiccups). So if that's any indication, if Tremor can run on the Rio Receiver it should catch on quickly.
Kenwood has a similar product, the Music Keg. Their version works like a CD changer with a removable hard drive cartridge.
And it's half the price and playsFLAC also (the MusicKeg is a re-branded PhatBox).
Pioneer has an in-dash unit like Sony's for around ~$2K but you can't even rip MP3's from ISO-9660 discs on that. Besides, who wants to spend all that time trying to rerip and recatalog everything on another box?
An iPod or a portable drive like the PhatBox is the way to go.
What I meant was, usually the files would become 75% of their original
size after compression, and at best get around 60% of their original size. Nothing really gets around
50%.
Actually, some types of music will get better compression than that, like some classical and jazz. I have some Ella Fitzgerald that gets 5:1.
But usually classical gets around 50%, pop/rock gets 60%, and death metal 70%. I have a comparison of different genres and different codecs on the FLAC site:
Slashdot Mirror
Right here. Or here for FLAC.
Josh
Yeah, because, you know, that's just what consumers want.
Still, there are some holes in Revolutions that are pretty gaping. I think they got pressure from the studios that it was too long, or to make a marketing gimmick out of it like so: 1) cut out the philosophical stuff, leave all of the formulaic rah-rah machine/zion battle (notice a lot of other scenes that feel like they just end too quickly, like when Neo gets to cry for like 2 seconds when Trinity dies; 2) give it all back in the super-extended-directors-cut-special-edition DVD, which will probably come out after everyone's bought the regular-super-special-edition of the trilogy. Everybody (almost) wins.
Only occasionally. Flak works better for that.
Josh
P.S. m-w.com says:
Etymology: German, from Fliegerabwehrkanonen, from Flieger (flyer) + Abwehr (defense) + Kanonen (cannons)
What would happen if a real election went through where these things were used, then after the fact it was discovered that there was tampering? I guess it's too much to expect to have a punch-card backup plan.
Why? It can play FLAC, which is lossless.
Josh
Kenwood makes the MusicKeg, a rebranded Phatbox, which plays FLAC and I believe you can get firmware from PhatNoise to play Vorbis also. They are still working on optimizations to Tremor to play the highest quality levels smoothly.
Josh
The thing that you do not want to do is be a nut case. Don't bash Microsoft...
I guess that eliminates all of us.
First the Hussein brothers, now this. Did Hammurabi just get promoted or something?
1. you rear-end some guy in your car because someone rear-ended you
2. the guy you rear ended is an executive and you do some "serious" physical damage to him
3. he talks to his lawyer, who finds out how much insurance you've got and how much equity there is in your house, and whatever else you "own"
4. they sue you for 2x that; you settle for 1x or maybe lose the case
Talk to a lawyer or insurance broker about this. If the've been doing it a while they're sure to have lots of stories for you.
People bring this up all the time but it never seems to occur to them that you encode only once but decode many times, and as long as encoding is at least as fast as ripping, the encoding speed doesn't really matter.
So what's left is the few % difference in file size. For that you get a slew of features that are much more useful to a user (unless you plan to only ever listen to your music on a Windows box). The FLAC features page spells these out.
Josh
Well, no, it's more than "none". There is a list of hardware devices that support FLAC on the homepage. And there are a few more in the works. The C reference codec and low decode complexity make it relatively simple to add FLAC support to devices.
Josh
Yes, Arson, Burrrn, burnatonce, and now there's a plugin for Nero. There's probably some more I forgot about.
Josh
Sorry, I should have said "libvorbis decodes to float samples" (I believe). But the basic problem remains, that in order to make the FLAC+Vorbis thing work would require standardizing the representation of decoded samples which is not practical and doesn't really have any advantages outside this particular untried idea.
Kind of. The command-line decoder has switches --skip and --until to decode a specific section, which you could pipe back into the encoder again.
It's possible to make a tool like vorbiscut that will split on frame boundaries.
For more info see here
One idea that would be really cool is if they could get acheive lossless compression by noting the differences between the original and the .OGG, and appending that to the .OGG. Then if you can just strip off the added info when you make copies to restricted-space devices. The only question is whether this can be done with a competitive compression ratio.
This has been suggested before, but would require all Vorbis decoders to decode to the exact same result, which is not practical (Vorbis decodes to float samples).
Not so, they are already integrated, i.e. you can already encode to raw FLAC or Ogg FLAC with the command-line flac encoder. FLAC packets are embeddable in an Ogg container just as easily as Vorbis ones.
There's a list on the sidebar of the FLAC homepage.
I guess the question is, what's holding back consumer electronics companies from implementing OGG and FLAC support?
In the case of the AudioTron, they are getting the full court press from Microsoft to do WMA lossless, and knowing Microsoft this will be to the exclusion of all others. I made a good case on their mailing list that with moderate work (and I was willing to help), the AT would be able to decode FLAC natively. Their response has always been "we tried it and it's not fast enough", despite the fact that identical hardware in other devices (Rio Receiver, PhatBox) can decode FLAC fine.
But no matter, other manufacturers are providing a choice, and the list is growing. Recently the ReQuest guys have added FLAC support to their ARQ boxes. So time will tell what consumers really want.
No, native FLAC will live on; teaming with Xiph will mean better integration with Ogg tools in general.
Minor point, but the tags are not part of the Ogg container. FLAC implements tags the same way as Vorbis does, as one of the initial packets, so they are available in raw FLAC as well as Ogg FLAC.
Let's see, at [pulls # out of ass] 10 cents a minute, that's 190,000 compute-years just to break even! OK, so maybe they will be able to charge more but they must be planning on a pretty sizable market. Or recoup rendering Toy Story sequels.
Wow, didn't realize how soon; the PhatBox guys have already tried it.
I think they were using a fixed-point implementation (see here). Maybe (probably) Tremor is a more optimal implementation. I suspect we'll find out soon enough.
The chip used in the Rio Receiver I believe is pretty common in other designs (PhatBox, Empeg/Rio Car, AudioTron) and seems like it's becoming the de facto measuring stick for whether or not a codec will run in consumer hardware.
On the other hand, there has been work to build replacement clients for the Rio Receiver that use FLAC lossless compression, and that apparently works pretty well. So the current thinking is to transcode .ogg to flac at the server level. Or just to rip everything to flac (which requires a whole lot more disk space. :( )
FLAC adoption happened relatively fast after a free integer decoder library was available (though it is LGPL, not BSD, which has caused some hiccups). So if that's any indication, if Tremor can run on the Rio Receiver it should catch on quickly.
And it's half the price and plays FLAC also (the MusicKeg is a re-branded PhatBox).
Pioneer has an in-dash unit like Sony's for around ~$2K but you can't even rip MP3's from ISO-9660 discs on that. Besides, who wants to spend all that time trying to rerip and recatalog everything on another box?
An iPod or a portable drive like the PhatBox is the way to go.
Josh
Actually, some types of music will get better compression than that, like some classical and jazz. I have some Ella Fitzgerald that gets 5:1. But usually classical gets around 50%, pop/rock gets 60%, and death metal 70%. I have a comparison of different genres and different codecs on the FLAC site:
http://flac.sf.net/comparison.html
Since the KT guys haven't even released an encoder yet there's no way to see how they measure up.