there may be a recent ruling that clarified this and made downloading allowable, but I'm not aware of it.
The Copyright Board of Canada handed down a decision last December that includes their interpretation that the Copyright Act does not address the source of a private copy:
There is no requirement in Part VIII that the source copy be a non-infringing copy. Hence, it is not relevant whether the source of the track is a pre-owned recording, a borrowed CD, or a track downloaded from the Internet.
With a well-conceived indexing, wouldn't the search be proportional to the base 2 logarithm of that number ?
Assuming they precalculate every combination, maybe. But 222 trillion MD5 sums at 16 bytes each is a few petabytes, and it's doubtful that they have that much storage available.
Debian's security would only be compromised if this allowed creating a package with a desired MD5 sum. All this appears to do is tries MD5 on certain strings (built from from a limited character set) until it finds a string with an MD5 that matches the given one.
The only thing that makes this remotely feasible is the limited character set and the length limit, which puts the total possible combinations it looks through at about 2.9 trillion. If they were to use uppercase letters as well, the total number of possibilities becomes about 222 trillion, and the search would take a lot longer.
That's what the Blue Book spec is for. Audio data on Blue Book discs is Red Book compatible, and the CD-ROM data is ignored by audio CD players because of the non-Red Book compliance of that session.
Corrupted CDs don't have Red Book compliant data, yet are to be played by devices designed for Red Book discs.
This one is, since AFAIK there's no corruption of the data on the CD that violates the established standards, just a piece of software that blocks your PC from accessing the Red Book tracks if it gets installed.
CDs that use other systems that deliberately malform certain pieces of data, on the other hand, violate the Red Book spec and should not be called CDs.
My impression from the reports about the copy prevention system used is that it is a valid hybrid data/audio CD - ripping is prevented only when the software on the CD, which blocks the CD from being recognized as a standard audio CD, is installed. Without the software, the CD shows up in ripping programs like any properly-made audio CD.
Yes, there are many copy prevention systems that deliberately malform the data on the CD, breaking its compliance with the Red Book spec, but this isn't one of them.
Boot loaders don't belong in the MBR, they belong in a partition's boot sector. All the MBR should have is a piece of code that looks for an active partition and runs its boot sector. If the Lilo and Grub authors would realize this, there'd be a much lesser chance of people's MBRs getting hosed.
Re:whats keeping xvid from doing mainstream...
on
XVID 1.0 Released
·
· Score: 1
It's no different than it is with LAME. MP3 is covered by patents, and the official LAME project only releases source code.
Re:Just like DivX, except....
on
XVID 1.0 Released
·
· Score: 2, Interesting
I don't know about DivX 5.11, but 5.1 had the stupid "feature" that it would shut down the program using it if it detected an active debugger. For more see this page, about halfway down (the Sept. 25th post).
They're both MPEG-4 codecs. MPEG-4 is supposed to work like MP3 is now in that there are many different encoders, and only one decoder is needed for all of them.
Re:whats keeping xvid from doing mainstream...
on
XVID 1.0 Released
·
· Score: 3, Informative
And where do you expect them to get the money to pay the patent licenses they'd need? By releasing only source code, they get considered an academic research project and don't have to pay for the patent licenses.
r3mix.net died because people actually did objective analysis of his recommended LAME settings and found they were crap. IIRC, the main guy behind it wasn't very accepting of criticism. Plus, he was a message board spammer.
The best replacement for r3mix.net in my opinion is HydrogenAudio . The forums are frequented by a lot of professionals, as well as developers of LAME, FLAC, Nero AAC, Musepack, Wavpack, and other codecs.
There's already at least one lossless codec out there (TTA, I believe) that borrows many design elements from FLAC. It's entirely possible that Apple has done the same, as there are no IP strings tied to FLAC.
but will have a tough time beating the speed/size ratio of Monkey's Audio.
Maybe on Windows, but on Mac, it should beat out MA easily. MA's touted speed only happens on x86 because of assembler optimizations. On Mac, MA is almost non-existant.
Actually, I think it's probably due to the fact that the algorithm needs to be optimized to run on the iPod's slower processor. Finding a compression algorithm that will run on a PC is easy, but it could be that they tried to port FLAC to the iPod and it just took too much CPU power.
Not likely. FLAC is very hardware-implementation friendly and takes very little CPU power to decode - on par with the fastest of MP3 decoders.
Lossless support doesn't mean much to me. Not so much because you can't fit as much music on an iPod when using it, but because the files are so large that the iPod will need to spin the hard drive far more often, draining the batteries more quickly. Ask a Rio Karma owner who has tried using FLAC and they'll tell you the battery life is cut by about 40% (Curiously, Vorbis on the Karma cuts the battery life even more than FLAC). And face facts, the iPod's battery life isn't that hot compared to the Karma or the iRiver players.
I do think lossless is good, but for versatility. I have all my CDs ripped to FLAC because that way when I want to convert to a certain format it takes at worst a small script - no CD swapping again and again. Or if I want to burn a redbook CD, I just fire up Nero or K3b depending on what OS I'm using.
For my iPod, I use foobar with the foo_nero plugin and Nero 6 to convert FLAC to M4A and preserve tags. The catch is that most M4A files created in other programs are known to cause iPods to lock up or reboot. I and others have found that if you make any kind of edit to the tags in iTunes (say, do a mass tag edit so all comments are "Transcoded from lossless") before uploading them, they'll play fine.
Because no player in that capacity range was included at all?
Jeez, people. The largest players there are the iPod Mini and the MuVo2 at 4GB each. Quit with the "why didn't they review this 20GB player?" comments.
Re:WinFS WILL be in the next version, just no netw
on
Microsoft Clips Longhorn
·
· Score: 2, Informative
Third, if you delete a junction,
Ack. I need to clarify this. What I mean by this is if you delete it in explorer, not using "junction -d".
Re:WinFS WILL be in the next version, just no netw
on
Microsoft Clips Longhorn
·
· Score: 3, Interesting
Oh, it gets better.
First, a folder and a junction pointing to it are *indistinguishable*. Looking in explorer, you can't tell which is the original folder and which is the junction.
Second, it's possible to create a junction pointing to a parent folder - thus creating an infinite-depth tree. (This is why you can't hard link directories in *nix!)
Third, if you delete a junction, you also delete all of the contents of the folder the junction pointed to. The original folder remains, but it is left empty.
All these considered, I really wonder what the hell MS was thinking.
Slashdot Mirror
The Copyright Board of Canada handed down a decision last December that includes their interpretation that the Copyright Act does not address the source of a private copy:
There is no requirement in Part VIII that the source copy be a non-infringing copy. Hence, it is not relevant whether the source of the track is a pre-owned recording, a borrowed CD, or a track downloaded from the Internet.
(page 20, fifth paragraph)
Assuming they precalculate every combination, maybe. But 222 trillion MD5 sums at 16 bytes each is a few petabytes, and it's doubtful that they have that much storage available.
The only thing that makes this remotely feasible is the limited character set and the length limit, which puts the total possible combinations it looks through at about 2.9 trillion. If they were to use uppercase letters as well, the total number of possibilities becomes about 222 trillion, and the search would take a lot longer.
It's going to have to happen, since IE will enforce MIME types starting in XP SP2.
Corrupted CDs don't have Red Book compliant data, yet are to be played by devices designed for Red Book discs.
CDs that use other systems that deliberately malform certain pieces of data, on the other hand, violate the Red Book spec and should not be called CDs.
My impression from the reports about the copy prevention system used is that it is a valid hybrid data/audio CD - ripping is prevented only when the software on the CD, which blocks the CD from being recognized as a standard audio CD, is installed. Without the software, the CD shows up in ripping programs like any properly-made audio CD.
Yes, there are many copy prevention systems that deliberately malform the data on the CD, breaking its compliance with the Red Book spec, but this isn't one of them.
Boot loaders don't belong in the MBR, they belong in a partition's boot sector. All the MBR should have is a piece of code that looks for an active partition and runs its boot sector. If the Lilo and Grub authors would realize this, there'd be a much lesser chance of people's MBRs getting hosed.
It's no different than it is with LAME. MP3 is covered by patents, and the official LAME project only releases source code.
I don't know about DivX 5.11, but 5.1 had the stupid "feature" that it would shut down the program using it if it detected an active debugger. For more see this page, about halfway down (the Sept. 25th post).
They're both MPEG-4 codecs. MPEG-4 is supposed to work like MP3 is now in that there are many different encoders, and only one decoder is needed for all of them.
And where do you expect them to get the money to pay the patent licenses they'd need? By releasing only source code, they get considered an academic research project and don't have to pay for the patent licenses.
Because in the opinions of many at HydrogenAudio, they were regressions rather than improvements.
The best replacement for r3mix.net in my opinion is HydrogenAudio . The forums are frequented by a lot of professionals, as well as developers of LAME, FLAC, Nero AAC, Musepack, Wavpack, and other codecs.
The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom.
Only if you would care to show how it's bullshit.
There's already at least one lossless codec out there (TTA, I believe) that borrows many design elements from FLAC. It's entirely possible that Apple has done the same, as there are no IP strings tied to FLAC.
Maybe on Windows, but on Mac, it should beat out MA easily. MA's touted speed only happens on x86 because of assembler optimizations. On Mac, MA is almost non-existant.
Not likely. FLAC is very hardware-implementation friendly and takes very little CPU power to decode - on par with the fastest of MP3 decoders.
I do think lossless is good, but for versatility. I have all my CDs ripped to FLAC because that way when I want to convert to a certain format it takes at worst a small script - no CD swapping again and again. Or if I want to burn a redbook CD, I just fire up Nero or K3b depending on what OS I'm using.
For my iPod, I use foobar with the foo_nero plugin and Nero 6 to convert FLAC to M4A and preserve tags. The catch is that most M4A files created in other programs are known to cause iPods to lock up or reboot. I and others have found that if you make any kind of edit to the tags in iTunes (say, do a mass tag edit so all comments are "Transcoded from lossless") before uploading them, they'll play fine.
My mistake. I thought he was still referring to the 49.
Nope, he was wrong. As an earlier post says, the 48GII and 49G+ use ARM9 processors. The 48GII uses a 48MHz chip, and the 49G+ uses a 75MHz chip.
Because no player in that capacity range was included at all?
Jeez, people. The largest players there are the iPod Mini and the MuVo2 at 4GB each. Quit with the "why didn't they review this 20GB player?" comments.
Ack. I need to clarify this. What I mean by this is if you delete it in explorer, not using "junction -d".
Oh, it gets better.
First, a folder and a junction pointing to it are *indistinguishable*. Looking in explorer, you can't tell which is the original folder and which is the junction.
Second, it's possible to create a junction pointing to a parent folder - thus creating an infinite-depth tree. (This is why you can't hard link directories in *nix!)
Third, if you delete a junction, you also delete all of the contents of the folder the junction pointed to. The original folder remains, but it is left empty.
All these considered, I really wonder what the hell MS was thinking.