sales tax is only 'regressive' if you measure the expenditure as a percentage of income, which is totally arbitrary. that phony definition plays on people's classism to sway them one way or the other. sales tax when measured against the actual tax base is not regressive and in the US is actually more 'progressive' in that some goods you need to survive have no sales tax.
Most media devices with music playback abilities do not have the function to play ogg (or flac for that matter).
nope, there are dozens of devices, including portables, that play vorbis, and dozens that play flac. flac is particularly cheap to decode. a partial list:
And don't point out that some people aren't smart enough to understand, either, because it's the people who are smart enough to "know better" that are the problem. The "left side of the bell curve" is more likely to do what they're told because they understand that they don't know better.
What's funny (well, not ha-ha funny) is that this massive domestic spying and rights-trampling infrastructure that Joe the Plumber Republicans were all for is now in the hands of their arch nemesis.
"There's an old saying in Tennessee -- I know it's in Texas, probably in Tennessee -- that says, fool me once, shame on -- shame on you. Fool me -- you can't get fooled again." -- GWB
Until they start selling lossless formats without DRM....I am not interested in buying any content online. The second they start selling lossless without DRM...I'll be the first one in line, and I can afford to buy a lot.
I believe MS has finally set an appropriate value on their OS. $3.00 is a fair price.
Now governments of the world should mandate a price cap for all versions of XP, based on that value. Otherwise Microsoft is using price dumping to drive out competitors, an illegal tactic for a monopoly.
ah, but XP is not $3, it's still $199, MS is just donating $196 to charity, you see. good on the books too. everyone wins! (well, except the kids)
Maybe Apple thought FLAC was infringing on patents and didn't want to risk being the only user of it with deep pockets.
I debunked that idea here, here and here.
every method in FLAC is also in ALAC, which FLAC predates by several years. they know there is no patent threat.
for almost the exact same reasons they support mp3. FLAC is used much more than ALAC. FLAC is used for lossless distribution more than ALAC (zero for ALAC afaik). transcoding is not user friendly for their target audience.
My understanding is Apple Lossless was created because it could be implemented efficiently on an iPod using only integer math, which FLAC couldn't at the time.
that's incorrect, the FLAC decoder has always used only integer math and from the beginning was lower complexity that ALAC.
iTunes can certainly play FLAC (or Ogg or whatever else you want) by installing a QuickTime component that handles the format.
I think that has since broken but when working it basically "imports" into itunes (loading the whole file before playing, causing delay) via quicktime and does not support metadata.
the article claims that apple won't go with FLAC because we're against DRM. I don't think so; if we're to believe Steve then he's against it too. and there's nothing stopping apple from sticking FLAC in an mp4 container with fairplay, we can't prevent that anyway. aside from the principle of it, another reasone we're against it in FLAC is that DRM is doesn't belong in the codec layer, it's a layer on top.
apple's got nothing to fear from FLAC, it can actually be used to their advantage to get a leg up on the competition, since for lossless electronic distribution FLAC is becoming the de facto standard.
almost everyone else distributing lossless (except musicgiants) is using FLAC and/or WAV. it's supported by almost all s/w except itunes, hell you can even get wmp to play FLAC with some work.
re:TFA, lossless is not directly about quality, mp3 and aac both can be perceptually transparent for the most part, it's about (depending on your personality) perceived quality or format independence -- i.e. being able to transcode to the format you need without quality loss.
And, you can have my physical books when I'm dead and gone -- I don't personally foresee giving them up any time soon. Books have a warmth and tactile feedback that a cold, digital screen will never offer to me.
it occurred to me that people could have had the same reaction at the boundary of oral tradition and the printed word: "paper is so impersonal, it can never offer the subtlety, richness or emotion of verbal communication." it matters a lot what you're already used to. I agree printed books aren't going away any time soon but the next generations will be looking back at us the same way (once publishers give up on trying to prop up prices by creating artificial scarcity anyway).
The meaning of "huge" changes pretty fast in this industry.
The size difference between 128kbps MP3 and FLAC is 2x-8x. How long did it take for ipods to increase capacity by 2x-8x?
not sure what you mean, but most of them except some of the chinese portables are easily available here. iaudio is a favorite for flac on a portable. for home stereo, in my experience the squeezebox and sonos are fantastic.
Also note that flac has just changed the format, thus breaking backwards compatibility. the FLAC format has never broken backwards compatibility. format changes are always backward-compatible improvements and hardware makers get the implementation long before changes are public so there are never compatibility problems.
Third, the FLAC *programming API* changed, FLAC 1.0 files can still be decoded using FLAC 1.2. But can new files be played with the old API? yes
My point was about creating hardware based portable music players as these are the main driver of the MP3 format at present. What would be the good of a portable player if it was only able to play files created with old versions of the encoding software. that limitation does not exist.
When the API is STABLE it may be adpoted by hardware manufacturers who will start making portable music players that support the format. perhaps you haven't seen http://flac.sourceforge.net/links.html#hardware
that is temporarily entertaining for you but ultimately pointless; they will not get it. next time you apply for a job and they ask for a bunch of info so they can do a criminal background check, etc, ask *them* (everyone who's touching your file) for the same info so you can run a background check on them (for all the same BS reasons they say they need to check you out) and hear their reactions. they have no problem seeing how ridiculous it is but due to a pervasive culture of servitude, most people literally cannot understand the other side.
Re:Things like this are easy to fix.
on
Google's Evil NDA
·
· Score: 4, Informative
this will work less and less, especially at big companies. the basic problem is that the people who make these policy decisions are totally insulated from any negative effects of the policy. if google unknowningly turned down someone who would have gone on to make them billions because s/he didn't want to sign the nda, how would they ever know? they only feel pain when something goes wrong that their current policy doesn't cover. so the policies get more and more ridiculous because it's impossible to do a proper cost/benefit analysis on them.
that's why you have nda's, non-competes, work-for-hire, background checks, drug tests in so many places whether they make sense or not. all it will take is for one guy who got through all that to go postal at some tech company and next month everyone will be doing a mandatory psych battery on all applicants.
I have not profiled libFLAC for ARM. yes 1.1.4 should be faster for ARM and 1.2.0 will be faster still. but my original point still applies, that libFLAC has to do much more than that reverse engineered alac decoder. for example, are you turning off md5 checking? that will save 15% decode time right there; by default libFLAC will do the md5sum until there is a seek. if libFLAC had to only worry about 16-bit stereo samples, many things could be sped up.
this applies to the complexity as well. if this is really a showstopper, there are other limited FLAC decoder implementations like in ffmpeg that may be simpler and/or faster. but comparing alac in m4a, where you are already getting tags, seeking, etc by your existing m4a handler, to libFLAC complexity is not apples-to-apples.
but I can see the usefulness of a simple FLAC decoder implementation that only handles 16-bit stereo.
I've seen both. ALAC and FLAC decode about the same with the source I have here.
and that source is... ?
The advantage to ALAC is that it has a nice transport - mp4 (m4a)
can you please describe how m4a is a nicer transport? anyway, FLAC can be encapsulated in m4a the same way ALAC is so it's a moot point.
and nice encoder (iTunes)
no one can add support for a codec to itunes except apple. if you would like FLAC support in itunes please tell them
Performance is neck-and-neck, otherwise.
I ask yet again, please provide some evidence for that claim. it is totally counterintuitive once you understand the design of both codecs, that FLAC's much lower decode complexity by nature will translate more easily into a faster decoder implementation, which is corroborated by the evidence I gave.
Source simplicity, which matters none to real people, is much in ALAC's favor. FLAC looks an awful lot like other Xiph products' source - very busy, and very little whitespace (i=1+23|more; all over the place), and SOOOOO many files, even if it compiles to a rather small 40 KB (decoder only)... ALAC's source, ala Hammertime(ton), is a stroll in the park (easy) compared to FLAC's busy downtown streets and back alleyways (forever lost).
I don't see what that has to do with anything, but your "ALAC source" by Hammerton is based on reverse engineering and only supports a subset of ALAC. a FLAC decoder which only supported such a subset of FLAC would be drastically shorter.
Relatively, no one uses either, but more no ones use FLAC.
please provide some evidence for that claim. lossless is a niche, yes, but among that niche FLAC is much more popular. this is also intuitive since FLAC has been around longer, is supported in many more devices and software, has more features, is non-proprietary, is faster, and compresses more. but in any case here is some evidence: 2007 HA poll 2006 HA poll
Slashdot Mirror
not only that but intel has pissed off a lot of the g1 owners by their incriminating silence about trim support in g1 drives.
sales tax is only 'regressive' if you measure the expenditure as a percentage of income, which is totally arbitrary. that phony definition plays on people's classism to sway them one way or the other. sales tax when measured against the actual tax base is not regressive and in the US is actually more 'progressive' in that some goods you need to survive have no sales tax.
Most media devices with music playback abilities do not have the function to play ogg (or flac for that matter).
nope, there are dozens of devices, including portables, that play vorbis, and dozens that play flac. flac is particularly cheap to decode. a partial list:
http://flac.sourceforge.net/links.html#hardware
http://wiki.xiph.org/index.php/PortablePlayers
And don't point out that some people aren't smart enough to understand, either, because it's the people who are smart enough to "know better" that are the problem. The "left side of the bell curve" is more likely to do what they're told because they understand that they don't know better.
that is absolutely backward.
the best way I know to find out you were not first at something is to post on slashdot that you were.
"There's an old saying in Tennessee -- I know it's in Texas, probably in Tennessee -- that says, fool me once, shame on -- shame on you. Fool me -- you can't get fooled again." -- GWB
Until they start selling lossless formats without DRM....I am not interested in buying any content online. The second they start selling lossless without DRM...I'll be the first one in line, and I can afford to buy a lot.
http://flac.sourceforge.net/links.html#music
ah, but XP is not $3, it's still $199, MS is just donating $196 to charity, you see. good on the books too. everyone wins! (well, except the kids)
I debunked that idea here, here and here.
every method in FLAC is also in ALAC, which FLAC predates by several years. they know there is no patent threat.
for almost the exact same reasons they support mp3. FLAC is used much more than ALAC. FLAC is used for lossless distribution more than ALAC (zero for ALAC afaik). transcoding is not user friendly for their target audience.
that's incorrect, the FLAC decoder has always used only integer math and from the beginning was lower complexity that ALAC.
iTunes can certainly play FLAC (or Ogg or whatever else you want) by installing a QuickTime component that handles the format.
I think that has since broken but when working it basically "imports" into itunes (loading the whole file before playing, causing delay) via quicktime and does not support metadata.
the article claims that apple won't go with FLAC because we're against DRM. I don't think so; if we're to believe Steve then he's against it too. and there's nothing stopping apple from sticking FLAC in an mp4 container with fairplay, we can't prevent that anyway. aside from the principle of it, another reasone we're against it in FLAC is that DRM is doesn't belong in the codec layer, it's a layer on top.
apple's got nothing to fear from FLAC, it can actually be used to their advantage to get a leg up on the competition, since for lossless electronic distribution FLAC is becoming the de facto standard.
...make some noise; here's one place to start: http://flac.sourceforge.net/itunes.html
almost everyone else distributing lossless (except musicgiants) is using FLAC and/or WAV. it's supported by almost all s/w except itunes, hell you can even get wmp to play FLAC with some work.
re:TFA, lossless is not directly about quality, mp3 and aac both can be perceptually transparent for the most part, it's about (depending on your personality) perceived quality or format independence -- i.e. being able to transcode to the format you need without quality loss.
it occurred to me that people could have had the same reaction at the boundary of oral tradition and the printed word: "paper is so impersonal, it can never offer the subtlety, richness or emotion of verbal communication." it matters a lot what you're already used to. I agree printed books aren't going away any time soon but the next generations will be looking back at us the same way (once publishers give up on trying to prop up prices by creating artificial scarcity anyway).
The meaning of "huge" changes pretty fast in this industry. The size difference between 128kbps MP3 and FLAC is 2x-8x. How long did it take for ipods to increase capacity by 2x-8x?
not sure what you mean, but most of them except some of the chinese portables are easily available here. iaudio is a favorite for flac on a portable. for home stereo, in my experience the squeezebox and sonos are fantastic.
http://www.theymightbegiants.com/album-venue.htm
that is temporarily entertaining for you but ultimately pointless; they will not get it. next time you apply for a job and they ask for a bunch of info so they can do a criminal background check, etc, ask *them* (everyone who's touching your file) for the same info so you can run a background check on them (for all the same BS reasons they say they need to check you out) and hear their reactions. they have no problem seeing how ridiculous it is but due to a pervasive culture of servitude, most people literally cannot understand the other side.
this will work less and less, especially at big companies. the basic problem is that the people who make these policy decisions are totally insulated from any negative effects of the policy. if google unknowningly turned down someone who would have gone on to make them billions because s/he didn't want to sign the nda, how would they ever know? they only feel pain when something goes wrong that their current policy doesn't cover. so the policies get more and more ridiculous because it's impossible to do a proper cost/benefit analysis on them.
that's why you have nda's, non-competes, work-for-hire, background checks, drug tests in so many places whether they make sense or not. all it will take is for one guy who got through all that to go postal at some tech company and next month everyone will be doing a mandatory psych battery on all applicants.
cool, now we're getting somewhere.
I have not profiled libFLAC for ARM. yes 1.1.4 should be faster for ARM and 1.2.0 will be faster still. but my original point still applies, that libFLAC has to do much more than that reverse engineered alac decoder. for example, are you turning off md5 checking? that will save 15% decode time right there; by default libFLAC will do the md5sum until there is a seek. if libFLAC had to only worry about 16-bit stereo samples, many things could be sped up.
this applies to the complexity as well. if this is really a showstopper, there are other limited FLAC decoder implementations like in ffmpeg that may be simpler and/or faster. but comparing alac in m4a, where you are already getting tags, seeking, etc by your existing m4a handler, to libFLAC complexity is not apples-to-apples.
but I can see the usefulness of a simple FLAC decoder implementation that only handles 16-bit stereo.
side question, are you using gcc on ARM?
and that source is... ?
The advantage to ALAC is that it has a nice transport - mp4 (m4a)
can you please describe how m4a is a nicer transport? anyway, FLAC can be encapsulated in m4a the same way ALAC is so it's a moot point.
and nice encoder (iTunes)
no one can add support for a codec to itunes except apple. if you would like FLAC support in itunes please tell them
Performance is neck-and-neck, otherwise.
I ask yet again, please provide some evidence for that claim. it is totally counterintuitive once you understand the design of both codecs, that FLAC's much lower decode complexity by nature will translate more easily into a faster decoder implementation, which is corroborated by the evidence I gave.
Source simplicity, which matters none to real people, is much in ALAC's favor. FLAC looks an awful lot like other Xiph products' source - very busy, and very little whitespace (i=1+23|more; all over the place), and SOOOOO many files, even if it compiles to a rather small 40 KB (decoder only)... ALAC's source, ala Hammertime(ton), is a stroll in the park (easy) compared to FLAC's busy downtown streets and back alleyways (forever lost).
I don't see what that has to do with anything, but your "ALAC source" by Hammerton is based on reverse engineering and only supports a subset of ALAC. a FLAC decoder which only supported such a subset of FLAC would be drastically shorter.
Relatively, no one uses either, but more no ones use FLAC.
please provide some evidence for that claim. lossless is a niche, yes, but among that niche FLAC is much more popular. this is also intuitive since FLAC has been around longer, is supported in many more devices and software, has more features, is non-proprietary, is faster, and compresses more. but in any case here is some evidence:
2007 HA poll
2006 HA poll
http://web.inter.nl.net/users/hvdh/lossless/lossle ss.htm
if you have some contrary evidence (snide remarks don't count), please post it.
that's not true, aside from compressing more, FLAC decodes significantly faster than ALAC. see http://flac.sourceforge.net/comparison.html