I want an HD DVD format - why would I want want to buy one called blurry-disc? I want higher-resolution, I don't want it blurry! Surely I should just go and buy this one called "HD-DVD", which is well, High Definition DVD?
In any format war between a cool-sounding name and a (extended-)three-letter-acronym, bet on the TLA. VHS beat betamax. DVD beat laserdisc. MP3 and AAC beat Ogg Vorbis.
The only reason blurry-disc is even a contender is Sony's bundling with the PS3. Nobody actually wants a blurry-disc player; they want High Def DVDs. Normal people understand that HD-DVD is an upgrade from DVD, whereas blurry-disc is no such thing. It's an incompatible format as far as the masses are concerned, just like betamax. Not better, just different and more expensive (see betamax). The HD-DVD TLA is understood, the name blurry disc is not. That's why it will fail, and why Sony should just give up - they've yet to win a format war anyway (see MemoryStick, Betamax, Betacam, MO-disc, MiniDisc, ATRAC, SDDS, SACD, UMD).
Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do. Internally, Barcelona is a very nice RISC core capable of doing so many things at once its insane. The only thing that performs better is a GPU, and that's only because they're thrown at embarassingly parallel problems. The fastest general purpose CPUs come from Intel and AMD, and it has nothing to do with instruction set.
AMD64, and the new Core2 and Barcelona chips are very nice chips. 16 64-bit registers, 16 128-bit registers, complete IEEE-754 floating point support, integer and floating-point SIMD instructions, out-of-order execution, streaming stores and hardware prefetch. Add to that multiple cores with very fast busses, massive caches - with multichip cache coherency - and the ability to run any code compiled in the last 25 years. What's not to like?
For information, here is the text of my complaint.
The BBC's insistence on using DRM ('Draconian Restrictions on Media') technology for IP broadcasts is in breach of its mandate. When organisations such as the ITU standardise on video formats such as H.264 and AAC for internet-based audio and video, it is unacceptable for the BBC to force users into purchasing a particular third-party component in order to watch paid-for content.
Limitation of viewing to users of Microsoft or Apple systems is unfair to those users who don't use or don't wish to buy such systems. Thousands of licence-payers would like to be able to view BBC content over the internet on their own devices - such devices include systems made by Nintendo, Sony, Sun, Gnu and others. Therefore the BBC's statement that they can't "put an exact timeframe on when BBC iPlayer will be available for Mac users" is blinkered, when it claims to "aim to make its content as widely available as possible and has always taken a platform agnostic approach to its internet services". Such a statement, in the light of the lack of platform support, is demonstrably false.
The complaint therefore is, in brief: The BBC's internet broadcasts must use open standards (such as H.264 and AAC), and not limit access by using particular vendors technology.
Actually no, gravity is a Law: something observable which has always held true. If you throw an apple in the air, it will always come down.
Newton's Theory of Gravity, which is "Bodies attract each other with a force equal to the product of their masses divided by the square of the distance between them", is a Theory; from this theory, we can then hypothesise the concept of escape velocity: that two bodies can move apart at such a velocity that the deceleration force of gravity will never cause the velocity to reach zero and turn the object. We can test this hypothesis, by building rockets, and reinforce the Theory of Gravity, even though it contradicts the previously-known Law of Gravity. The Theory explains why the Law no longer holds, and the Law adjusts to: If you throw an apple in the air, it will always come down unless you throw it hard enough.
It's already got a perfectly good name. DRM stands for "Draconian Restrictions on Media". That "Digital Rights Management" nonsense is Orwellian doublespeak. It does nothing to "manage" anyones "rights". Copyright can be subverted even with DRM.
It's called Draconian Restrictions on Media. It is an illegal control on fair-use. Circumventing it is legal; the DMCA unconstitutional.
Draconian Restrictions on Media has a nice ring to it. Nice and clear about its purpose, which is to force people to buy multiple copies of the same bits. It does nothing to stop pirates, who will duplicate discs, copy-protection and all. All it does is annoy the people who have already bought the disc.
Trying to make bits uncopyable is like trying to make water not wet
Out-of-order execution giving multiple accumulators processing data in parallel.
All of your complaints are about the assembly-level interface to the processor, not the processor design itself. As I said, all of this is gravy. The assembly itself is analysed for data dependencies, and as much as possible of it is executed in parallel. Most of the data movement you seem to be complaining about doesn't physically happen. You may write "movd (%esp), %eax", but the processor sees "you want this 32-bit word which I just pushed (which hasn't actually been written memory) to be used as an accumulator. Fine, next time you refer to %eax in this branch I'll use that data". Meanwhile, another possible branch is doing something different, and it has its own idea about what data might be in %eax.
However, MP3 also refers to MPEG-2 part 3 layer 3, which is an enhancement to MPEG-1 part 3 layer 3 supporting more than two channels. So I was right in that AAC existed in the same specification as MPEG-2 audio layer 3, but not the original MPEG-1 audio layer 3.
Just a note (yes, replying to myself): My code above is not only semantically identical to the posted version (aside from storing the allocated pointers somewhere), but also identical from a flow-control point of view The two probably compile to the exact same assembly, since there's only so many ways you can say test %eax; jz label;.
The difference is, my version is properly nested, so that you can see exactly what exists at what point in the code. This is what Dijkstra was talking about.
int allocstuff(void **a, void **b) {
(*a) = malloc(100);
if (*a)
{
(*b) = malloc(100);
if (*b)
{
return 0;
}
free(*a);
(*a) = NULL;
}
return -1; } There. No memory leaking. Your free(b) is after a return. And even if you succeed, you leak, since you don't keep hold of your allocations. And this was supposed to demonstrate the virtue of GOTO how?
Advanced Audio Coding is MPEG-2 part 7, with enhancements in MPEG-4 part 3. It's not a replacement for MP3 (MPEG-2 part 3), it's an alternative, which has existed for just as long as MP3 has.
If only because it keeps us tied to the x86 instruction set. If we didn't have the luxury of increasing the transistor count by an order of magnitude every few years, we'd have to rely on better processor design.
I'm just going to refer you to my comment made earlier today when discussing a "new, better" processor architecture. Because there's always someone who thinks we are somehow "hindered" by the fact that we can still run 30-year old software unmodified on new hardware.
However, the basic problem in creating a new kind of architecture that can emulate x86 faster than real x86 hardware is that Intel (and AMD although their resources are a lot less) can play that game too, by making a new kind of x86 chip that implements the x86 instruction set as an emulation.
In fact, this is exactly how modern Intel and AMD chips work. Internally, they are RISC, with an instruction reordering unit and a vector unit. All the horrible instructions in the x86 ISA are microcoded, allowing the greater part of silicon to be dedicated to making particular instructions fast (media processing, mainly). There isn't actually hardware for things like the AAA instruction, since nobody cares about the speed of BCD calculations; there is hardware for single-cycle floating-point dot-products. The miniscule number of registers everyone complains about is irrelevant, since internally the out-of-order execution unit has dozens of shadow registers - only calculations which are correctly predicated actually make it as far as user-visible registers.
Given then, the fact that Intel and AMD are already essentially emulating x86 in (fast, parallelised, speculative) hardware, I doubt that anyone else can come up with a faster chip by doing basically the same thing. Transmeta tried this and failed.
Since then there have been a number of attempts at removing the out-of-order unit, basically transferring execution control to the compiler, such as these people are doing. Intels' attempt, EPIC, was a disaster. I think the idea is folly, as advances in compiler design can't make old programs faster (unless you're using open source), whereas a faster execution unit with better branch prediction and parallel speculative execution will make all programs running on the chip faster (and therefore sell more chips).
Exactly. If you try to put a bent CD into a CD drive, you're obviously not going to be able to read it. But that doesn't mean its not recoverable.
To recover data from a CD, you can simply photograph it at high enough resolution. Even with huge scratches, even with parts of the disc physically missing, you can recover the data exactly as it was encoded. How? Reed Solomon code. Quoth wikipedia:
The result is a CIRC that can completely correct error bursts up to 4000 bits, or about 2.5 mm on the disc surface. This code is so strong that most CD playback errors are almost certainly caused by tracking errors that cause the laser to jump track, not by uncorrectable error bursts
That's true with 1.5gig, but the 3gig standard now means you no longer need dual-link (unless you need an alpha-channel, in which case it's back to dual-link for 1080p (but an alpha channel is not going to be needed for sending to a monitor)).
It's close. Coax I can get for 20p per metre, whereas cat3 comes out at 10p per metre, so either way, its dirt cheap.
But cat3 can't handle the data rates. We're talking 3Gbps here - much higher than even cat5 can do. If you were to bond a dozen cat3's, you would find that the coax is far cheaper.
An HDMI enabled video card is *exactly* what some have been waiting for. Now we can preview our work on a TV screen, which has a different colour space to computer monitors.
Actually, no. If you really wanted digital video on a TV screen you'd be using HD-SDI (with embedded AES audio). You can get some nice cards from Bluefish.
HDMI is a useless specification. It does nothing not already done by HD-SDI (and over co-ax, the cheapest possible cabling!), except for the Digital Compatibility Prevention.
Somehow, I'm reminded of this comic: http://www.vgcats.com/comics/?strip_id=212
Boeing have a term for navigational instrument failure - for example when the altimeter reads several thousand feet below actual altitude:
They call it CFIT - Controlled Flight Into Terrain.
I want an HD DVD format - why would I want want to buy one called blurry-disc? I want higher-resolution, I don't want it blurry! Surely I should just go and buy this one called "HD-DVD", which is well, High Definition DVD?
In any format war between a cool-sounding name and a (extended-)three-letter-acronym, bet on the TLA. VHS beat betamax. DVD beat laserdisc. MP3 and AAC beat Ogg Vorbis.
The only reason blurry-disc is even a contender is Sony's bundling with the PS3. Nobody actually wants a blurry-disc player; they want High Def DVDs. Normal people understand that HD-DVD is an upgrade from DVD, whereas blurry-disc is no such thing. It's an incompatible format as far as the masses are concerned, just like betamax. Not better, just different and more expensive (see betamax). The HD-DVD TLA is understood, the name blurry disc is not. That's why it will fail, and why Sony should just give up - they've yet to win a format war anyway (see MemoryStick, Betamax, Betacam, MO-disc, MiniDisc, ATRAC, SDDS, SACD, UMD).
We have flying cars. They're called helicopters.
Yay for piracy!
Now, we just need to keep downloading torrents and DVDs will get cheaper, too!
*Nothing to do with the lack of demand for crap music, obviously.
Not again.
Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do. Internally, Barcelona is a very nice RISC core capable of doing so many things at once its insane. The only thing that performs better is a GPU, and that's only because they're thrown at embarassingly parallel problems. The fastest general purpose CPUs come from Intel and AMD, and it has nothing to do with instruction set.
AMD64, and the new Core2 and Barcelona chips are very nice chips. 16 64-bit registers, 16 128-bit registers, complete IEEE-754 floating point support, integer and floating-point SIMD instructions, out-of-order execution, streaming stores and hardware prefetch. Add to that multiple cores with very fast busses, massive caches - with multichip cache coherency - and the ability to run any code compiled in the last 25 years. What's not to like?
Good idea. I just have.
For information, here is the text of my complaint.
The BBC's insistence on using DRM ('Draconian Restrictions on Media') technology for IP broadcasts is in breach of its mandate. When organisations such as the ITU standardise on video formats such as H.264 and AAC for internet-based audio and video, it is unacceptable for the BBC to force users into purchasing a particular third-party component in order to watch paid-for content.
Limitation of viewing to users of Microsoft or Apple systems is unfair to those users who don't use or don't wish to buy such systems. Thousands of licence-payers would like to be able to view BBC content over the internet on their own devices - such devices include systems made by Nintendo, Sony, Sun, Gnu and others. Therefore the BBC's statement that they can't "put an exact timeframe on when BBC iPlayer will be available for Mac users" is blinkered, when it claims to "aim to make its content as widely available as possible and has always taken a platform agnostic approach to its internet services". Such a statement, in the light of the lack of platform support, is demonstrably false.
The complaint therefore is, in brief: The BBC's internet broadcasts must use open standards (such as H.264 and AAC), and not limit access by using particular vendors technology.
Actually no, gravity is a Law: something observable which has always held true. If you throw an apple in the air, it will always come down.
Newton's Theory of Gravity, which is "Bodies attract each other with a force equal to the product of their masses divided by the square of the distance between them", is a Theory; from this theory, we can then hypothesise the concept of escape velocity: that two bodies can move apart at such a velocity that the deceleration force of gravity will never cause the velocity to reach zero and turn the object. We can test this hypothesis, by building rockets, and reinforce the Theory of Gravity, even though it contradicts the previously-known Law of Gravity. The Theory explains why the Law no longer holds, and the Law adjusts to: If you throw an apple in the air, it will always come down unless you throw it hard enough.
It's called Draconian Restrictions on Media. It is an illegal control on fair-use. Circumventing it is legal; the DMCA unconstitutional.
Draconian Restrictions on Media has a nice ring to it. Nice and clear about its purpose, which is to force people to buy multiple copies of the same bits. It does nothing to stop pirates, who will duplicate discs, copy-protection and all. All it does is annoy the people who have already bought the disc.
It's not "Patch Tuesday", it's "Exploit Wednesday".
Release your exploit in the wild the day after the second Tuesday of the month, knowing that there will be nothing to stop you for an entire month!
Why start an attack on any other day?
It's a new implementation of an aging instruction set. Or are you seriously suggesting Core 2 or Opteron is the same, architecturally, as the 8086?
Register renaming.
Register renaming, cache and hardware prefetcher.
Data cache.
Out-of-order execution giving multiple accumulators processing data in parallel.
All of your complaints are about the assembly-level interface to the processor, not the processor design itself. As I said, all of this is gravy. The assembly itself is analysed for data dependencies, and as much as possible of it is executed in parallel. Most of the data movement you seem to be complaining about doesn't physically happen. You may write "movd (%esp), %eax", but the processor sees "you want this 32-bit word which I just pushed (which hasn't actually been written memory) to be used as an accumulator. Fine, next time you refer to %eax in this branch I'll use that data". Meanwhile, another possible branch is doing something different, and it has its own idea about what data might be in %eax.
Instruction set != architecture.
I stand corrected.
However, MP3 also refers to MPEG-2 part 3 layer 3, which is an enhancement to MPEG-1 part 3 layer 3 supporting more than two channels. So I was right in that AAC existed in the same specification as MPEG-2 audio layer 3, but not the original MPEG-1 audio layer 3.
Just a note (yes, replying to myself): My code above is not only semantically identical to the posted version (aside from storing the allocated pointers somewhere), but also identical from a flow-control point of view The two probably compile to the exact same assembly, since there's only so many ways you can say test %eax; jz label;.
The difference is, my version is properly nested, so that you can see exactly what exists at what point in the code. This is what Dijkstra was talking about.
int allocstuff(void **a, void **b)
{
(*a) = malloc(100);
if (*a)
{
(*b) = malloc(100);
if (*b)
{
return 0;
}
free(*a);
(*a) = NULL;
}
return -1;
}
There. No memory leaking. Your free(b) is after a return. And even if you succeed, you leak, since you don't keep hold of your allocations. And this was supposed to demonstrate the virtue of GOTO how?
Close.
Advanced Audio Coding is MPEG-2 part 7, with enhancements in MPEG-4 part 3. It's not a replacement for MP3 (MPEG-2 part 3), it's an alternative, which has existed for just as long as MP3 has.
See ISO/IEC 13818-7 and ISO/IEC 14496-3.
I'm just going to refer you to my comment made earlier today when discussing a "new, better" processor architecture. Because there's always someone who thinks we are somehow "hindered" by the fact that we can still run 30-year old software unmodified on new hardware.
See here.
In fact, this is exactly how modern Intel and AMD chips work. Internally, they are RISC, with an instruction reordering unit and a vector unit. All the horrible instructions in the x86 ISA are microcoded, allowing the greater part of silicon to be dedicated to making particular instructions fast (media processing, mainly). There isn't actually hardware for things like the AAA instruction, since nobody cares about the speed of BCD calculations; there is hardware for single-cycle floating-point dot-products. The miniscule number of registers everyone complains about is irrelevant, since internally the out-of-order execution unit has dozens of shadow registers - only calculations which are correctly predicated actually make it as far as user-visible registers.
Given then, the fact that Intel and AMD are already essentially emulating x86 in (fast, parallelised, speculative) hardware, I doubt that anyone else can come up with a faster chip by doing basically the same thing. Transmeta tried this and failed.
Since then there have been a number of attempts at removing the out-of-order unit, basically transferring execution control to the compiler, such as these people are doing. Intels' attempt, EPIC, was a disaster. I think the idea is folly, as advances in compiler design can't make old programs faster (unless you're using open source), whereas a faster execution unit with better branch prediction and parallel speculative execution will make all programs running on the chip faster (and therefore sell more chips).
Here.
That is all.
I believe this case is most definitely the Evil Empire of Red Book.
To recover data from a CD, you can simply photograph it at high enough resolution. Even with huge scratches, even with parts of the disc physically missing, you can recover the data exactly as it was encoded. How? Reed Solomon code .
Quoth wikipedia:
That's true with 1.5gig, but the 3gig standard now means you no longer need dual-link (unless you need an alpha-channel, in which case it's back to dual-link for 1080p (but an alpha channel is not going to be needed for sending to a monitor)).
It's close. Coax I can get for 20p per metre, whereas cat3 comes out at 10p per metre, so either way, its dirt cheap.
But cat3 can't handle the data rates. We're talking 3Gbps here - much higher than even cat5 can do. If you were to bond a dozen cat3's, you would find that the coax is far cheaper.
Actually, no. If you really wanted digital video on a TV screen you'd be using HD-SDI (with embedded AES audio). You can get some nice cards from Bluefish.
HDMI is a useless specification. It does nothing not already done by HD-SDI (and over co-ax, the cheapest possible cabling!), except for the Digital Compatibility Prevention.