And the "superior sound quality" of both DVD-A and SACD is well outside the range of human hearing.
Okay, before we talk frequency response let's talk sample precision. The biggest limitation of 16-bit samples is an effective 98dB of dynamic range. Today's audio engineers aren't making effective use of the CD's dynamic range, and the reality is that compressors are still being utilized despite the CD being the supposed answer to this problem, which was of course much more pronounced in the days of vinyl. I'd say the fact that compressors are still being utilized is indicative that 98dB is simply not enough for the way all music is currently being engineered, not just for orchestral recordings but for rock and other genres as well. The two solutions to this problem are a better audio engineering process (i.e. better training for audio engineers), or updating the technology to resolve the issue. I'll tell you now... the former is simply not going to happen, and I see the latter as the only practical solution.
A 24-bit system offers 146 dB of dynamic range. While this seems like something which would only appeal to audiophiles who insist on absolute perfection in their orchestral recordings, the truth is that audiophiles tend to prefer vinyl even though any vinyl, even a 78 RPM record (which has a dynamic range of ~75dB) will actually have worse dynamic range than a CD due to compromises made in the vinyl engineering/cutting process. So who then benefits from greater dynamic range? The answer is everyone... 146 dB of dynamic range is more than enough to eliminate an audio engineer's need to use compressors except in the case of the extraordinarly inept. While yes, 98 dB
should've been enough as well, today's audio engineers are simply failing to make use of it properly. It's sad that a technological problem is needed to address the ineptitude of today's audio engineers, but the ultimate argument is that it's ridiculous to impose unnecessary constraints on audio engineering if better technology is capable of removing them.
This is all covered quite well in this article. And here is another article which provides support for a simple claim: uncompressed recordings sound better.
In terms of frequency response, yes, human hearing extends only to 20kHz, and the Red Book stipulates that the glass masters of all CDs should be produced by passing the final cut through a 20kHz lowpass filter (the theoretical maximum frequency response of a CD is ~22kHz). What this process ignores, however, is that higher frequencies, while inaudible, are still tangible. While this area hasn't been extensively studied and is much harder to quantify, the tangibility of a live performance versus a recorded one is one of the key distinguishing characteristics, and while most of this tangibility typically comes from the bass side of things and not the treble, simply approaching the audio engineering process from an entirely psychoacoustic perspective will leave you with sound drastically different from the live performance regardless...
Distribution of RSS isn't so much a problem as is the fact that web servers are hammered by RSS connections as RSS syndicators must continue polling the web server to identify when the RSS document updates.
This problem is easily addressed with multicasting. All a server need do is send a multicast datagram to notify all RSS syndicators that the RSS document has been updated, at which time the syndicators can fetch the new document.
I agree. PDTP seems to be much better suited to corporate use than BitTorrent. BitTorrent's main drawback seems to be the lack of a mature, well supported C implementation, without which integration into other native code applications is extremely difficult as all applications using BitTorrent must bundle a Python runtime.
It wasn't a concert, it was an orchestral version of The Last Time and the sample was barely audible. Regardless, it didn't stop the Rolling Stones from successfully suing for 100% of the publishing rights...
Not only is it backwards compatible, but thanks to Perl 6's new modular architecture, Perl 5 code will simply include a separate parser/compiler which will generate code which will execute through the Parrot runtime, which adds a number of optimization benefits (at runtime, even) not currently possible through the current Perl 5 compiler/parser/runtime mush.
Consequently, Perl 5 code should run faster under Perl 6.
Anyone know of a production quality native code implementation of the FreeNet protocols? I'd love to set up a FreeNet node, however all the systems I have free to dedicate to that purpose are not powerful enough and lack sufficient RAM to run the standard FreeNet Java implementation.
"Well, no!" is the proper response. I'm sure most of us have been using > 4MB RAM on 32-bit architectures for years.
The real limitation is 4GB of total VM space (2^32 = 4294967296 bytes) for operating systems running on 32-bit architectures. This can be very disadvantageous, especially on architectures such as OS X which prebind applications to increase performance. When prebinding is utilized, each library and executable is pre-assigned a portion of the VM space to run in, which means that if you install too many programs you may run out of available VM space. This problem is remedied on the G5, which uses the G5's 64-bit functionality to manage a 64-bit VM space (2^64 = 18,446,744,073,709,551,616 bytes, or 18 exabytes) however no one process can utilize more than 4GB at a time due to the use of 32-bit pointers. This is where a real 64-bit operating system like Solaris, Irix, Tru64, etc. is handy, at least for databases and other applications which need to crunch large data sets in memory.
There are other areas where having a 64-bit VM space alone is a major boon, one of the most notable being memory-mapped I/O. On a 32-bit architecture, processes typically can't memory map a >2GB file, but on a 64-bit architecture, with 18 exabytes of VM space to blow, processes can mmap to their heart's desire without worry.
The problems seems to be with the inability of BitTorrent to serve directory heirarchies, and the difficulty of generating.torrent files for a large repository of 10,000 files or more, plus the resource usage of running a BitTorrent tracker for each file.
It's fairly clear from the article he's a California man suing a Greely, CO firm in Denver, CO, most likely because it's an interstate matter. Greeley is in Weld county... one would assume the suit would take place in the county seat (which I believe is Greeley)... but I don't really know too much in matters of interstate law. Perhaps one of the sides requested a change of venue...
How far would backwards compatibility with XBox 1 go?
Backwards compatibility with XBox 1 would mean that the XBox hacking community immediately has a means by which to run arbitrary code on the XBox 2... by utilizing the buffer overflows in MechAssault and 007: Agent Under Fire. Is this really how Microsoft wants to start out? Could they really sandbox something like VirtualPC well enough to prevent users from booting illegal copies of games, or modifying the contents of their hard drives?
"The Microsoft(R) WOW64 (Windows(R) on Windows) subsystem will allow most 32-bit applications to launch seamlessly on 64-bit Windows," said Brian Marr, Windows product manager. "WOW64 is designed to provide interoperability and great performance on AMD64 processors across the 32/64-bit boundaries. As customers migrate to 64-bit Windows XP and Windows Server, they will have a code base that will support both 32- and 64-bit applications."
While it's wonderful Linux understands multiple ABIs natively, Windows does not, and utilizes WoW to seamlessly launch 32-bit applications on 64-bit builds of Windows.
I already covered this on another thread of this story, but the primary advantage of AMD64 applications over IA32 is the increased number of registers that the AMD64 instruction set affords, 8 general purpose registers over the 4 provided by IA32. This can significantly improve performance as it reduces the chance code needs to hit cache or main memory in the event that 4 general purpose registers are not sufficient for the task at hand.
The primary advantage of AMD64 applications over IA32 is the increased number of registers that the AMD64 instruction set affords, 8 general purpose registers over the 4 provided by IA32. This can significantly improve performance as it reduces the chance code needs to hit cache or main memory in the event that 4 general purpose registers are not sufficient for the task at hand.
Will the AMD64 build include Windows Media Player? It was left out of the IA64 version due to what I can only assume are 64-bit cleanliness issues with the DirectShow API and WMP code. I can only assume that an AMD64 build would allow 32-bit builds of DirectShow and WMP which execute through the WoW abstraction layer.
I was very surprised to find no mention of RCA's VideoDisc Format, which allowed video to be stored on vinyl records and was the first consumer video format.
Slashdot Mirror
Okay, before we talk frequency response let's talk sample precision. The biggest limitation of 16-bit samples is an effective 98dB of dynamic range. Today's audio engineers aren't making effective use of the CD's dynamic range, and the reality is that compressors are still being utilized despite the CD being the supposed answer to this problem, which was of course much more pronounced in the days of vinyl. I'd say the fact that compressors are still being utilized is indicative that 98dB is simply not enough for the way all music is currently being engineered, not just for orchestral recordings but for rock and other genres as well. The two solutions to this problem are a better audio engineering process (i.e. better training for audio engineers), or updating the technology to resolve the issue. I'll tell you now... the former is simply not going to happen, and I see the latter as the only practical solution.
A 24-bit system offers 146 dB of dynamic range. While this seems like something which would only appeal to audiophiles who insist on absolute perfection in their orchestral recordings, the truth is that audiophiles tend to prefer vinyl even though any vinyl, even a 78 RPM record (which has a dynamic range of ~75dB) will actually have worse dynamic range than a CD due to compromises made in the vinyl engineering/cutting process. So who then benefits from greater dynamic range? The answer is everyone... 146 dB of dynamic range is more than enough to eliminate an audio engineer's need to use compressors except in the case of the extraordinarly inept. While yes, 98 dB should've been enough as well, today's audio engineers are simply failing to make use of it properly. It's sad that a technological problem is needed to address the ineptitude of today's audio engineers, but the ultimate argument is that it's ridiculous to impose unnecessary constraints on audio engineering if better technology is capable of removing them.
This is all covered quite well in this article. And here is another article which provides support for a simple claim: uncompressed recordings sound better.
In terms of frequency response, yes, human hearing extends only to 20kHz, and the Red Book stipulates that the glass masters of all CDs should be produced by passing the final cut through a 20kHz lowpass filter (the theoretical maximum frequency response of a CD is ~22kHz). What this process ignores, however, is that higher frequencies, while inaudible, are still tangible. While this area hasn't been extensively studied and is much harder to quantify, the tangibility of a live performance versus a recorded one is one of the key distinguishing characteristics, and while most of this tangibility typically comes from the bass side of things and not the treble, simply approaching the audio engineering process from an entirely psychoacoustic perspective will leave you with sound drastically different from the live performance regardless...
This problem is easily addressed with multicasting. All a server need do is send a multicast datagram to notify all RSS syndicators that the RSS document has been updated, at which time the syndicators can fetch the new document.
Unfortunately, PDTP seems a bit far from completion
How about... the Matrix?
Unless you predicted a sci-fi powerhouse coming out of the creators of Assassins and Bound...
...how insane does this make the team that entered a motorcycle?
This sounds like a problem with these cards in general. What stores would accept them? Wouldn't they be suspicious of credit card fraud?
I remember this earlier Slashdot article discussing a similar technology. How long before these things are commodity hardware?
It wasn't a concert, it was an orchestral version of The Last Time and the sample was barely audible. Regardless, it didn't stop the Rolling Stones from successfully suing for 100% of the publishing rights...
It's called morphine.
Consequently, Perl 5 code should run faster under Perl 6.
Anyone know of a production quality native code implementation of the FreeNet protocols? I'd love to set up a FreeNet node, however all the systems I have free to dedicate to that purpose are not powerful enough and lack sufficient RAM to run the standard FreeNet Java implementation.
"Well, no!" is the proper response. I'm sure most of us have been using > 4MB RAM on 32-bit architectures for years.
The real limitation is 4GB of total VM space (2^32 = 4294967296 bytes) for operating systems running on 32-bit architectures. This can be very disadvantageous, especially on architectures such as OS X which prebind applications to increase performance. When prebinding is utilized, each library and executable is pre-assigned a portion of the VM space to run in, which means that if you install too many programs you may run out of available VM space. This problem is remedied on the G5, which uses the G5's 64-bit functionality to manage a 64-bit VM space (2^64 = 18,446,744,073,709,551,616 bytes, or 18 exabytes) however no one process can utilize more than 4GB at a time due to the use of 32-bit pointers. This is where a real 64-bit operating system like Solaris, Irix, Tru64, etc. is handy, at least for databases and other applications which need to crunch large data sets in memory.
There are other areas where having a 64-bit VM space alone is a major boon, one of the most notable being memory-mapped I/O. On a 32-bit architecture, processes typically can't memory map a >2GB file, but on a 64-bit architecture, with 18 exabytes of VM space to blow, processes can mmap to their heart's desire without worry.
Check out the Dell 2001FP. With a 16ms response, it's more than adequate for gaming.
For that much money, I think I'd rather own a car
It seems there are protocols which are working to overcome these limitations.
Q: Can I use PDTP now?
A: No, PDTP is still several months away from a beta release.
Doesn't look like it's better than BitTorrent for now. Good design though, looks promising.
Indeed, and this is exactly what FreeNet is designed to do:
http://freenet.sourceforge.net/
Perhaps the fear of every government everywhere, FreeNet allows for secure and anonymous communication.
It's fairly clear from the article he's a California man suing a Greely, CO firm in Denver, CO, most likely because it's an interstate matter. Greeley is in Weld county... one would assume the suit would take place in the county seat (which I believe is Greeley)... but I don't really know too much in matters of interstate law. Perhaps one of the sides requested a change of venue...
How far would backwards compatibility with XBox 1 go? Backwards compatibility with XBox 1 would mean that the XBox hacking community immediately has a means by which to run arbitrary code on the XBox 2... by utilizing the buffer overflows in MechAssault and 007: Agent Under Fire. Is this really how Microsoft wants to start out? Could they really sandbox something like VirtualPC well enough to prevent users from booting illegal copies of games, or modifying the contents of their hard drives?
While it's wonderful Linux understands multiple ABIs natively, Windows does not, and utilizes WoW to seamlessly launch 32-bit applications on 64-bit builds of Windows.
I already covered this on another thread of this story, but the primary advantage of AMD64 applications over IA32 is the increased number of registers that the AMD64 instruction set affords, 8 general purpose registers over the 4 provided by IA32. This can significantly improve performance as it reduces the chance code needs to hit cache or main memory in the event that 4 general purpose registers are not sufficient for the task at hand.
The primary advantage of AMD64 applications over IA32 is the increased number of registers that the AMD64 instruction set affords, 8 general purpose registers over the 4 provided by IA32. This can significantly improve performance as it reduces the chance code needs to hit cache or main memory in the event that 4 general purpose registers are not sufficient for the task at hand.
Will the AMD64 build include Windows Media Player? It was left out of the IA64 version due to what I can only assume are 64-bit cleanliness issues with the DirectShow API and WMP code. I can only assume that an AMD64 build would allow 32-bit builds of DirectShow and WMP which execute through the WoW abstraction layer.
I was very surprised to find no mention of RCA's VideoDisc Format, which allowed video to be stored on vinyl records and was the first consumer video format.
Perhaps if you could retrofit a Mac motherboard into it...