Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: 1) I don't know of any device that can 'see how a chip worked'. There are devices that allow you to reverse-engineer a chip through physical means. You can literally shave off one thin layer at a time, and use a high power microscope, and then apply image-analysis algorithms to build masks to make chip duplicates and to determine how it works. /Andrew Excactly what I've written: "The only way to see how a chip works is to put it under a micro-scope, make a foto of the metal-layer, etch this layer away, make a foto of the next metal-layer... etc.. This is a time-consuming and a very difficult process which doesn't give the expected results in 99.% of all cases. Back-Engineering in the chip industrie is almost impossible!" I work in the micro-electronics world. The most favourite process used at the moment is HCMOS7 (in the digital world). In the digital world, the desing-complexity doubles each two years (Moore's law which still holds up). What makes this possible? Simple, each two years, we come up with a new process that is smaller (0.5-0.35-0.25-0.18 micro-meter). Maybee it's possible with a 120 layer digital IC, to shave of each layer, analyse and so build a 3D-image of a chip. But one thing is sure, that only gives you a 'flatened' representation of all the combined FSM's that are behind the design. I yet have to see the first workstation that has the capacity to analyse this flatened FSM and to produce the HDL-code for it! I've never heard of reverse-engineer. But I've heard of espionage. Ie, it seems to be much easyer to steal the design than to reverse-engineer. (And I bet it's much easyer!) What you say, can be done for analog ICs. Why? Simple, you just can't make analog electronics smaller. (You can't put 5mW MOS-FETS inside a 2x40W IC amplifier!). Cheers, Ralph - ever tried to reverse engineer a 20 milion+ design? -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
On Thu, 16 Mar 2000, Stainless Steel Rat wrote: Hi, Umm... how does this contradict anything that I said? Damn, I'm sorry! I misread your mail. My eyes were reading it, but my mind were thinking on the discussion on doing so on a portable. I also have post some mails regarding that: a USB or Firewire, computer-oriented device. sorry, *---(*)---**-- Francisco J. Montilla System Network administrator [EMAIL PROTECTED] irc: pukkaSevilleSpain INSFLUG (LiNUX) Coordinator: www.insflug.org - ftp.insflug.org - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Fri, 17 Mar 2000 | The entire point of USB is to move hardware *outside* of the host machine. | If you put the encoder inside, then there is no reason for a USB device. | *Looks at his USB keyboard and mouse* . odd I never usually have my | keyboard and mouse inside my PC, but then maybe you're a closet Amiga | fan... You know, you are being really dense. | The point of USB was to introduce a better serial port system No, it was not. The point of USB was create something better than Apple Desktop Bus, something with higher throughput, more devices in the chain, hardware independent, and hot-swappable. | - the current UART devices etc. are too slow to cope with today's | applications. The UARTs for your aforementioned mouse and keyboard are more than adequate, are they not? | USB was invented to be a small, simple and high-spec interface for | transferring data between devices, not necessarily to put them outside | the PC. I have yet to see a USB device other than the host controller itself to be located inside the case. -- Rat [EMAIL PROTECTED]\ When not in use, Happy Fun Ball should be Minion of Nathan - Nathan says Hi! \ returned to its special container and PGP Key: at a key server near you! \ kept under refrigeration. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
1) I don't know of any device that can 'see how a chip worked'. There are devices that allow you to reverse-engineer a chip through physical means. You can literally shave off one thin layer at a time, and use a high power microscope, and then apply image-analysis algorithms to build masks to make chip duplicates and to determine how it works. /Andrew - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
1) I don't know of any device that can 'see how a chip worked'. 2) You're probabably confusing ROM/RAMs with CPUs and DSPs.. To be honest, I have no way in hell of knowing WHAT was done. This is what my friend told me, which is total BS, but, I did view some of the prototype stuff they worked on, such as MP3 -ATRAC which then using a MD data drive they "burned" onto a MD. I don' t know how it was done, I was only there for 5 minutes, however durning this 5 minutes they made a entire 74 minute disc. YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
On 15 Mar 2000, Stainless Steel Rat wrote: Hi, * "Magic" [EMAIL PROTECTED] on Wed, 15 Mar 2000 | Possibly it would, although it may need to be a rather faster ATRAC. | Remember this whole thread started because I suggested that it would be | better to implement ATRAC encoding at the PC rather than at the MD because | it would free up the USB bus. USB 1.1 maxes out at 12Mb/s (bit vs. Byte), or 90MB/minute. A 74 minute CD is 640MB, or ~8MB/minute. Kick the math around and, after you figure in something like a 5% loss due to overhead, you can dump raw, 16-bit PCM down the USB pipe about 10 times faster than real-time playback. Encoding on the host machine saves you nothing. I disagree, the original point was to be able to transfer to MD at several times normal speed. If you have to "record" at higher speeds, the servos and laser need to have greater accuracy, and as somebody from Aiwa mentioned, increase a lot the price. Not to mention if it has to encode data additionally... I guess the most viable way will be a special data unit, that has only to write already encoded data to the MD with no or little encoding. greets, *---(*)---**-- Francisco J. Montilla System Network administrator [EMAIL PROTECTED] irc: pukkaSevilleSpain INSFLUG (LiNUX) Coordinator: www.insflug.org - ftp.insflug.org - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Thursday, March 16, 2000 3:10 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface SCSI over USB :). But really, Firewire/iLink/IEEE-1394 is infinitely superior for bulk data, currently 400Mb/s vs. USB's relatively pathetic 12Mb/s. Of course, nobody makes MO drives that can keep up with data transfer rates that fast. True, but the advantage of using USB is that most PC's have it built in as standard, whereas to use SCSI or FireWire systems would mean I need to add 2 cards (1 encoder / MD Card and one FireWire or SCSI interface) which would boost the price up. IF we get to a point where FireWire is a standard interface built into most PCs then at that point it would be the better choice. Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
Umm... how does this contradict anything that I said? * Francisco Jose Montilla [EMAIL PROTECTED] on Thu, 16 Mar 2000 | I disagree, the original point was to be able to transfer to MD at | several times normal speed. Is the 10 times normal playback speed throughput capacity of USB 1.1 not "several times normal speed"? | If you have to "record" at higher speeds, the servos and laser need to | have greater accuracy, and as somebody from Aiwa mentioned, increase a | lot the price. Your point being? | Not to mention if it has to encode data additionally... An MD recorder's ATRAC circuit converts 16-bit linear PCM to ATRAC already, by definition. Moving the ATRAC encoding out of the recorder seems stupid to me. The only "extra" encoding that the host and USB device need to do is wrapping PCM packets inside USB packets in a fashion similar to SCSI over USB, which is computationally trivial. | I guess the most viable way will be a special data unit, that has | only to write already encoded data to the MD with no or little encoding. Huh? This makes no sense to me. -- Rat [EMAIL PROTECTED]\ Warning: pregnant women, the elderly, and Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged PGP Key: at a key server near you! \ exposure to Happy Fun Ball. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
Which brings me back around to the original point that implementing real time ATRAC in software on today's desktop is not going to happen. Well, I think that there's a small qualifier here. I've been watching this thread for a long time now, keeping my trap shut. What it comes down to is that while ATRAC *could* be implemented in realtime (if not now, then in the near future), but that the complexity of the algorithm makes it a stupid decision. It'd be cheaper to just make a small ATRAC board that carries the $5 ASIC on-board, or some other embedded solution. It's the same argument as any other form of emulation -- sure, you *can* run your Playstation games on a computer with Bleem or such, but will that make people stop buying Playstations? No. The hardware inside a Playstation is designed for a small niche, and ATRAC chips are the same way. It's does only one thing, but it's very, very good at it. A general-purpose computer is better utilized for more generalized tasks. My US$0.02, /Andrew - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
There have been several non-professional software programs made in my area by some people who were able to see how the chip worked and was able to get the code from it (my friends dad worked at a place that had a chip reader). Not that great, but realtime. BTW people who have been around for a while, the freak is back. -J.R. Moore YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
Even if a high-speed ATRAC chip is used as opposed to software ATRAC, I think the encoder would be better off at the PC end as this allows more utilisation of the limited bandwidth USB ports. Well, I'll just give my standard response to this sort of argument -- USB is designed for peripherals, not for media storage or transfer, IMHO. If I'm going to be doing data storage or retrieval, I'd be using SCSI. Honestly, making some kind of hardware-based solution makes the most sense, but if you're trying to save bandwidth on an already-CPU-intensive bus (AFAIK, USB is still essentially an interrupt-driven technology, causing CPU use every time a packet travels the wire), offloading the encoding to an already-working CPU might be a poor decision. Transaction 1 - US$0.02 Transaction 2 - US$0.02 --- SubtotalUS$0.04 :wq!, /Andrew - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* Andrew Hobgood [EMAIL PROTECTED] on Wed, 15 Mar 2000 | Well, I'll just give my standard response to this sort of argument -- USB | is designed for peripherals, not for media storage or transfer, IMHO. If | I'm going to be doing data storage or retrieval, I'd be using SCSI. SCSI over USB :). But really, Firewire/iLink/IEEE-1394 is infinitely superior for bulk data, currently 400Mb/s vs. USB's relatively pathetic 12Mb/s. Of course, nobody makes MO drives that can keep up with data transfer rates that fast. -- Rat [EMAIL PROTECTED]\ When not in use, Happy Fun Ball should be Minion of Nathan - Nathan says Hi! \ returned to its special container and PGP Key: at a key server near you! \ kept under refrigeration. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Wed, 15 Mar 2000 | Possibly it would, although it may need to be a rather faster ATRAC. | Remember this whole thread started because I suggested that it would be | better to implement ATRAC encoding at the PC rather than at the MD because | it would free up the USB bus. USB 1.1 maxes out at 12Mb/s (bit vs. Byte), or 90MB/minute. A 74 minute CD is 640MB, or ~8MB/minute. Kick the math around and, after you figure in something like a 5% loss due to overhead, you can dump raw, 16-bit PCM down the USB pipe about 10 times faster than real-time playback. Encoding on the host machine saves you nothing. | Perhaps encoding on the PC shouldn't be in software but, as you suggest, | as hardware. Perhaps a modified form of sound card that outputs a special | ATRAC encoded stream at high speed. The entire point of USB is to move hardware *outside* of the host machine. If you put the encoder inside, then there is no reason for a USB device. -- Rat [EMAIL PROTECTED]\ Happy Fun Ball may stick to certain types Minion of Nathan - Nathan says Hi! \ of skin. PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Andrew Hobgood [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Wednesday, March 15, 2000 8:43 PM Subject: Re: MD: Sony's new Internet Audio Recording Interface Well, I think that there's a small qualifier here. I've been watching this thread for a long time now, keeping my trap shut. What it comes down to is that while ATRAC *could* be implemented in realtime (if not now, then in the near future), but that the complexity of the algorithm makes it a stupid decision. It'd be cheaper to just make a small ATRAC board that carries the $5 ASIC on-board, or some other embedded solution. Possibly it would, although it may need to be a rather faster ATRAC. Remember this whole thread started because I suggested that it would be better to implement ATRAC encoding at the PC rather than at the MD because it would free up the USB bus. Perhaps encoding on the PC shouldn't be in software but, as you suggest, as hardware. Perhaps a modified form of sound card that outputs a special ATRAC encoded stream at high speed. It's the same argument as any other form of emulation -- sure, you *can* run your Playstation games on a computer with Bleem or such, but will that make people stop buying Playstations? No. The hardware inside a Playstation is designed for a small niche, and ATRAC chips are the same way. It's does only one thing, but it's very, very good at it. A general-purpose computer is better utilized for more generalized tasks. Yes, but the difference there is you are attempting to emulate the whole PSX system, where-as I was merely suggesting that this be an alternative method of encoding to allow high-speed recording to MD via an interface (probably USB). Al I am in reality suggesting is a new version of the Sony MDH-10 drive but running from a USB port with the ATRAC encoder on the PC rather than in the unit. Even if a high-speed ATRAC chip is used as opposed to software ATRAC, I think the encoder would be better off at the PC end as this allows more utilisation of the limited bandwidth USB ports. Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Sun, 12 Mar 2000 | There's no reason why an MP3 encoder couldn't take this approach either - I | think LAME may even do just that! No, it does not. LAME is a set of patches to the psychoaccoustic model in the ISO reference implementation of the MP3 encoder. AFAIK, no MP3 encoder applies its psychoaccoustic model to its time-frequency distribution algorithm. They probably could, but there are two reasons they do not. One: it is a more complex algorithm, and not entirely understood even by the guys who wrote and maintain it at Sony. Two: (drum roll please) it is slower because of that greater complexity. Which brings me back around to the original point that implementing real time ATRAC in software on today's desktop is not going to happen. -- Rat [EMAIL PROTECTED]\ Caution: Happy Fun Ball may suddenly Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds. PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Sunday, March 12, 2000 6:16 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface Whosoever has told you that is full of crap. At the fundamental level, MP3 (MPEG-1 Layer III audio) has a pathetic time-frequency distribution model. At lower bitrates, 128Kbps (allegedly "near-CD quality) and below, audio signals with lots of high and low frequency sounds but relatively little in the middle get... "cropped" is the best way I can describe it. When the time-frequency block is full, any remaining signal gets thrown away, whether or not it is significant. I understand that Prince's "Raspberry Beret" is an "MP3 breaker" for this reason, but I have never made the comparison personally. There are many different approaches to encoding MP3 and what you have discribed is not the case for all of them. The quality of an MP3 can vary considerably from encoder to encoder at the same bitrate, and a song which breaks one encoder can sail through flawlessly on another. I know for a fact that Xing is hopeless with military brass-band type music (it made a mess of the theme to Monty Pythons Flying Circus even at 160bps) yet Fraunhoffer loved it (near perfect at 112bps!). ATRAC has a much more sophisticated time-frequency distribution model, one that uses the same psychoaccoustic model as the bit reduction algorithm. ATRAC is also designed to be an on-the-fly encoding system - MP3 is not. The result is that time-frequency blocks are allocated based on "density". Frequency ranges with more sound get more bandwidth; those with less sound get proportionally less bandwidth. There's no reason why an MP3 encoder couldn't take this approach either - I think LAME may even do just that! Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* Eric Woudenberg [EMAIL PROTECTED] on Sat, 11 Mar 2000 | I'm missing something. Didn't I demonstrate that MP3 (a more complex | coder than ATRAC) Whosoever has told you that is full of crap. At the fundamental level, MP3 (MPEG-1 Layer III audio) has a pathetic time-frequency distribution model. At lower bitrates, 128Kbps (allegedly "near-CD quality) and below, audio signals with lots of high and low frequency sounds but relatively little in the middle get... "cropped" is the best way I can describe it. When the time-frequency block is full, any remaining signal gets thrown away, whether or not it is significant. I understand that Prince's "Raspberry Beret" is an "MP3 breaker" for this reason, but I have never made the comparison personally. ATRAC has a much more sophisticated time-frequency distribution model, one that uses the same psychoaccoustic model as the bit reduction algorithm. The result is that time-frequency blocks are allocated based on "density". Frequency ranges with more sound get more bandwidth; those with less sound get proportionally less bandwidth. | runs at 3X realtime on my 500MHZ desktop machine? Do you still somehow | think ATRAC would be slower than realtime on such a machine? For sound quality as close to ATRAC 4 as MP3 is capable of achieving, yes. -- Rat [EMAIL PROTECTED]\ Happy Fun Ball contains a liquid core, Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should PGP Key: at a key server near you! \ not be touched, inhaled, or looked at. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: 100MHz SDRAM is cheap these days-- I got 128Mb for ukp80 inc vat and shipping more than enough for Windoze98 and some theoretical ATRAC encoder I would think. I would say I'm a bit puzzled as to why my machine is nearly 20% slower when I disable the motherboard's 1Mb cache as it is also only running at 100MHz. Is the cache SRAM and have fewer (or no) wait states? Reply privately if you wish. SRAM has no wait states. SDRAM has. SDRAM is only fast when you load/save executive adresses. SRAM is always fast. Cheers, Ralph -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: PrinceGaz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 08, 2000 3:26 PM Subject: Re: MD: Sony's new Internet Audio Recording Interface Who cares, Nick only ever issues a very mild warning after eg, prattling on about gun-control for days so this topic has to be okay. BTW I hope M Schumacher does well in the first F1 race of the season in Sydney this weekend. I think there is only going to be one way to get this solved and that is for somebody to write an ATRAC encoder on the PC based upon the ASIC system. Unfortunately I lack the expertise to write something that complex - is anyone else on this list up to the challenge? I think it can be done, there's no real reason why it wouldn't work, the only issue is whether it would work fast enough for real-time orr faster performance. I've seen many processes categorically stated that a PC could not do in real-time including MPEG decoding, controlling MIDI instruments, networking (yes, at one point this was 'impossible'), making a CD, printing a document, voice dictation, the list is virtually endless. After a lot of research and development all of these are now virtually second nature to every PC user! I see no reason why ATRAC Encoding could not be the same. There will be sceptics at first and it would probably take a few attempts to get it right, but I'm sure it can be done. I only wish I had the knowledge to write it myself (but then Sony would probably be after me for copying their system without permission). Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
- Original Message - From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Friday, March 10, 2000 3:46 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface But your Mazda Miata (your "consumer sports car") needs a lot of supertuning to even think about competing with my "stock" Shelby Cobra GT-350. The analogy is not all that good, though. I never was very good with analogies. The point is that the ATRAC chip in the MD only has one task to perform and it is very good at it. The Pentium chip in the PC has a lot of tasks to *oversee* - it is not actually performing all of them, it has other systems to do that. The graphics card is handling the display, the sound card is handling processing sound (even 3D positioning in some cases) and there are also extra processor/controller chips handling other aspects of system operation. This means the main CPU isn't actually doing as much as you would think until you need to perform a lot more calculations - it spends a lot of time "idle". The effect of this is that it has a lot more "time" to spare on running intense calculations that you would expect it to. I still maintain that it is not impossible for a real-time or faster ATRAC encoder to be produced, I just wonder what the system specification would be in order for it to run fast enough. My reckoning is that the spec. would be a lot lower than some would have us believe. Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: The point is that the ATRAC chip in the MD only has one task to perform and it is very good at it. The Pentium chip in the PC has a lot of tasks to *oversee* - it is not actually performing all of them, it has other systems to do that. The graphics card is handling the display, the sound card is handling processing sound (even 3D positioning in some cases) and there are also extra processor/controller chips handling other aspects of system operation. This means the main CPU isn't actually doing as much as you would think until you need to perform a lot more calculations - it spends a lot of time "idle". The effect of this is that it has a lot more "time" to spare on running intense calculations that you would expect it to. I still maintain that it is not impossible for a real-time or faster ATRAC encoder to be produced, I just wonder what the system specification would be in order for it to run fast enough. My reckoning is that the spec. would be a lot lower than some would have us believe. Magic And all that is tied together with a 33Mhz PCI bus (Which has an average performance of 33MB/s (PCI is ONLY fast when in burst mode. I/O with soundcards etc. is single-byte based!, unless the CPU invokes DMA transfer, but even then -in most cases-, the PCI bus is occupied and the CPU can't do anything!) Cheers, Ralph - Wondering at what speed the ATRAC-R-type DSP is running -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Fri, 10 Mar 2000 | I think there is only going to be one way to get this solved and that is for | somebody to write an ATRAC encoder on the PC based upon the ASIC system. | Unfortunately I lack the expertise to write something that complex - is | anyone else on this list up to the challenge? Emuating an ASIC in software? No, that is a bad idea. Remember when I said that emulation is slow? | I think it can be done, there's no real reason why it wouldn't work, the | only issue is whether it would work fast enough for real-time orr faster | performance. I've seen many processes categorically stated that a PC could | not do in real-time including MPEG decoding, controlling MIDI instruments, | networking (yes, at one point this was 'impossible'), making a CD, printing | a document, voice dictation, the list is virtually endless. Five or six years ago, the average desktop PC could not manage MPEG decoding at reasonable frame rates (16-24fps) at reasonable resolution (420 scan lines) in real time, and they were not fast enough to burn CD-Rs. As for the rest, I do not know where you get your information, but the Corvus Constellation worked just fine for 1MHz Apple ][s, MIDI has always had computer control capability, etc. Right about now, were I you I would seriosuly question my sources. -- Rat [EMAIL PROTECTED]\ Warning: pregnant women, the elderly, and Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged PGP Key: at a key server near you! \ exposure to Happy Fun Ball. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Ralph Smeets [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 10, 2000 12:28 PM Subject: Re: MD: Sony's new Internet Audio Recording Interface And all that is tied together with a 33Mhz PCI bus (Which has an average performance of 33MB/s (PCI is ONLY fast when in burst mode. I/O with soundcards etc. is single-byte based!, unless the CPU invokes DMA transfer, but even then -in most cases-, the PCI bus is occupied and the CPU can't do anything!) Can't argue with that, however, I would point out that you can do MPEG video encoding on a P3-400MHz system at 320x240 resolution in true colours, and that's *with* a 16 bit stereo audio stream and no hardware encoder (my 450MHz manages 16fps unassisted). I still find it hard to believe that a machine that can manage that wouldn't be able to do ATRAC encoding fast enough. Cheers, Ralph - Wondering at what speed the ATRAC-R-type DSP is running At a guess I'd say 35 MHz with 70MHz on-chip Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Friday, March 10, 2000 3:05 PM Subject: Re: MD: Sony's new Internet Audio Recording Interface Emuating an ASIC in software? No, that is a bad idea. Remember when I said that emulation is slow? I didn't say emulate the ASIC, I said devise a system based up it. The Windows caluclator is based upon an actual calculator, but it isn't an emulation. I have been arguing for a while that the best way to reproduce a system is not necessarily be emulation. Five or six years ago, the average desktop PC could not manage MPEG decoding at reasonable frame rates (16-24fps) at reasonable resolution (420 scan lines) in real time, and they were not fast enough to burn CD-Rs. As for the rest, I do not know where you get your information, but the Corvus Constellation worked just fine for 1MHz Apple ][s, MIDI has always had computer control capability, etc. Right about now, were I you I would seriosuly question my sources. If you go back far enough you'll find the idea of a computer in a chip was laughed at. The idea of a computer was itself rediculous until Charles Babbage came along. My point is that things move on, systems get better and can do more things, and so it is not impossible for a computer to do this task. It's no more challenging than any other "impossible" task a computer has ben asked to perform. I am 100% sure it can be done and I'm quite sure that the systems we currently have would be fast enough. If they aren't now then by the time such a system hit the market with the appropriate modifications made to an MD they very probably would be! Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Fri, 10 Mar 2000 | I didn't say emulate the ASIC, I said devise a system based up it. The | Windows caluclator is based upon an actual calculator, but it isn't an | emulation. I have been arguing for a while that the best way to reproduce a | system is not necessarily be emulation. The software guts of the Windows calculator are totally unlike those in the IC of a pocket calculator. They do the same thing, but they go about it in different ways. There are things that can be done in an ASIC that are just plain stupid to do the same way in software on a general purpose processor. Counting on your fingers is really easy for humans. Counting on fingers is not a good way to write mathematical software. [...] | If you go back far enough you'll find the idea of a computer in a chip was | laughed at. The idea of a computer was itself rediculous until Charles | Babbage came along. Actually, it was laughed at well through Babbage's life and death. None of his engines were ever built. | My point is that things move on, systems get better and can do more things, | and so it is not impossible for a computer to do this task. Tell me where I once stated that a desktop machine five years from now would be unable to perform ATRAC encoding in real time. I will save you the trouble: I never did. I said that a desktop machine today cannot perform ATRAC encoding in real time because it has to do in slow software what a dedicated DSP can do in a fast ASIC. -- Rat [EMAIL PROTECTED]\ Happy Fun Ball contains a liquid core, Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should PGP Key: at a key server near you! \ not be touched, inhaled, or looked at. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
RE: MD: Sony's new Internet Audio Recording Interface
Ralph Smeets wrote: On the PC, it's not only the ATRAC algorithm that's running, but also writing a packet of data received by the soundcard to memory, and writing this data back to disc. I just did an experiment. On my 350 Mhz Pentium II, I can write data to my old hard disk at 2.5 MB/sec, using 5% CPU time, so writing an ATRAC data stream (say 40KB/sec) would use ~ .1% of available CPU. I then ran Windows Sound Recorder (hint: probably not mega efficient) at 44.1kHz 16 bit stereo, requiring less than 1% CPU time. An 11.9 mS time frame gives me ~ 512 samples per channel, which is 256 * 9 FFT butterflies* per frame. Guessing 40 instructions per butterfly gives 256*9*40 operation per frame per channel, or 256*9*40*84 ops per channel per second, which is 15 Mips. You have to add bit allocation and so forth, so double this to get ~ 30 Mips. My CPU can do 350 Mips. simon * where a "butterfly" is a' = a * sin(w) + b * cos(w); b' = a * cos(w) + b * sin(w); and the sines and coses are obtained from a lookup table - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: * "Magic" [EMAIL PROTECTED] on Wed, 08 Mar 2000 | Fair enough, however, modern DIMMs are much much faster than the RAM you | would find in the MD. The processor is also much much faster. If it takes me | 3 instructions to do what the ATRAC chip does in 1, that means I can do it | at the same speed if my processor does instructions in 1/3 of the time. You are comparing apples and eggs. The ATRAC DSP does not work the same way a general purpose processor works. The measurement is not how many instructions they can process per second; the measurement is how much data they can process per second. And the fact remains that a dedicated DSP can process more data per second than any current generation desktop PC. that's my whole point. DSPs are designed to do 'number crunching'. I've been involved in the functional verification of the ST100 DSP core. Our team (including me) verifies also the design of the SH4 (The CPU you'll find in the DreamCast). DSP and CPU architectures are completely different. DSP's are optimized to keep the data flowing. However their are NOT designed to handle control tasks (Ie, handle interupts etc.). A CPU however is a very general purpose processor that has to be able to loads of things. Compare it with cars. If you look at a particular price-class, you'll find a wide range of cars. Varying from sporty cars to mini-vans. The sports-car will do one thing very well: Going Fast. The mini-van however will transport a lot for you, but they won't go very fast. If you build a DSP for one special purpose, you'll be able to optimize the core even more. Looking at the evolution of ATRAC, I believe that until the birth of ATRAC 3.x, Sony was unable to design an ATRAC encoder that was fast enough to do the encoding 'unoticable'. Why do I come to this conclussion, simple: - Sony knew how they could improve their algorithm and therefore build a decoder that could handle future encoding schemas. - ATRAC 3.0 and higher implements 3 frequency bands that can be modified. Ie, they aren't fixed like ATRAC 1 and 2. This requires a lot more processing power. Cheers, Ralph -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Ralph Smeets [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 09, 2000 9:06 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface [EMAIL PROTECTED] wrote: * "Magic" [EMAIL PROTECTED] on Wed, 08 Mar 2000 | Fair enough, however, modern DIMMs are much much faster than the RAM you | would find in the MD. The processor is also much much faster. If it takes me | 3 instructions to do what the ATRAC chip does in 1, that means I can do it | at the same speed if my processor does instructions in 1/3 of the time. You are comparing apples and eggs. The ATRAC DSP does not work the same way a general purpose processor works. The measurement is not how many instructions they can process per second; the measurement is how much data they can process per second. And the fact remains that a dedicated DSP can process more data per second than any current generation desktop PC. that's my whole point. DSPs are designed to do 'number crunching'. I've been involved in the functional verification of the ST100 DSP core. Our team (including me) verifies also the design of the SH4 (The CPU you'll find in the DreamCast). DSP and CPU architectures are completely different. DSP's are optimized to keep the data flowing. However their are NOT designed to handle control tasks (Ie, handle interupts etc.). A CPU however is a very general purpose processor that has to be able to loads of things. Compare it with cars. If you look at a particular price-class, you'll find a wide range of cars. Varying from sporty cars to mini-vans. The sports-car will do one thing very well: Going Fast. The mini-van however will transport a lot for you, but they won't go very fast. Ok. Now assume your sports car is built to be price-economical (ie. at a price that a large number of people can afford rather than absolute state-of-the-art technology that hardly anyone except the super-rich can afford). It would probably have a reasonable top speed, reasonable handling, look pretty good for all accounts a nice little consumer sports car. Now compare that with the Van. It's engine doesn't do a lot of work because it has been suped up - it has a didicated system handling steering, another handling suspention, it even has secondary engines to help maintain momentum when it moves. In fact, it has so many of these things in it that the actual engine itself really just handles more co-ordination of these other devices than anything else, and only has a high demand put on it when you need to really drive the system. say climbing a steep hill for example. Now assume that this engine is actually very very powerful - far more so than the engine in the sports car in terms of speed. The question is, will the suped-up van outperform the sports car? Given it's extra power advantage and assistance from other devices, I would think it probably could. If you build a DSP for one special purpose, you'll be able to optimize the core even more. Looking at the evolution of ATRAC, I believe that until the birth of ATRAC 3.x, Sony was unable to design an ATRAC encoder that was fast enough to do the encoding 'unoticable'. Why do I come to this conclussion, simple: - Sony knew how they could improve their algorithm and therefore build a decoder that could handle future encoding schemas. - ATRAC 3.0 and higher implements 3 frequency bands that can be modified. Ie, they aren't fixed like ATRAC 1 and 2. This requires a lot more processing power. There's also another thing to consider - size. It may be that a P166 could perform the ATRAC encoding, but an MD with a P166 processor in it wouldn't be portable and would probably require vast amounts of cooling to prevent it burning you if clipped to a belt! It could be that the power is there but *not* in the super-small componants required for a personal player. Take the Athlon 700MHz for example - it's a big big processor with a lot of cooling. They haven't made one small enough to fit in a laptop PC yet, let alone something as small as a portable MD!! Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
Magic wrote: Now compare that with the Van. It's engine doesn't do a lot of work because it has been suped up - it has a didicated system handling steering, another handling suspention, it even has secondary engines to help maintain momentum when it moves. In fact, it has so many of these things in it that the actual engine itself really just handles more co-ordination of these other devices than anything else, and only has a high demand put on it when you need to really drive the system. say climbing a steep hill for example. Now assume that this engine is actually very very powerful - far more so than the engine in the sports car in terms of speed. What have you been smoking? I got a mini-van and it only has one engine. It ain't suped-up. Yours must not be made in the Motor City. -- Jim Coon Not just another pretty mandolin picker. mailto:[EMAIL PROTECTED] If Gibson made cars, would they sound so sweet? My first web page http://www.tir.com/~liteways - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Thu, 09 Mar 2000 | Ok. Now assume your sports car is built to be price-economical (ie. at a | price that a large number of people can afford rather than absolute | state-of-the-art technology that hardly anyone except the super-rich can | afford). It would probably have a reasonable top speed, reasonable handling, | look pretty good for all accounts a nice little consumer sports car. But your Mazda Miata (your "consumer sports car") needs a lot of supertuning to even think about competing with my "stock" Shelby Cobra GT-350. The analogy is not all that good, though. -- Rat [EMAIL PROTECTED]\ Caution: Happy Fun Ball may suddenly Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds. PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
=== = NB: Over 50% of this message is QUOTED, please = = be more selective when quoting text = === [EMAIL PROTECTED] wrote: Hi, (Sorry I can't address you by name). Stainless Steel Rat [EMAIL PROTECTED] writes: * Eric Woudenberg [EMAIL PROTECTED] on Mon, 06 Mar 2000 | On what do you base this statement? My understanding of ATRAC (based | upon looking at an ATRAC decoder) is that the computational demands of | encoding ATRAC are similar to those for MP3. I would expect a software | ATRAC encoder to run about as fast as an MP3 encoder. If that were the case, then you would be able to encode MP3 streams that sound as good as ATRAC 4 (which they do not) in real time on your desktop (which you cannot at this time). As I mentioned previously, a Pentium II running at 400MHz is capable of turning SPDIF into 128Kbps MP3 in real time, if it is not doing anything else. The particular machine in question is a 64Mb system with fast/wide SCSI (so, no bottleneck there), using LAME. 128Kbps MP3s do not sound nearly as good as ATRAC 4, so I have to say that the computational loads are not comparable. Somehow my encoding times are quite different than yours, running LAME/Linux on a 500MHZ PIII, I get these times for encoding a 1 minute 44.1khz stereo signal: Output Bitrate (kbps): 32 64 128 256 320 User time (secs):15 16 21 21 19 At worst, this is 3 times faster than realtime. The ATRAC encoder is not significantly different in structure from MPEG 1 Layer I (a simpler encoder than MP3), so it is reasonable to expect that an ATRAC encoder would offer similar encoding times. Also, regarding the ATRAC ASIC, AFAIK (and please correct me if I'm wrong), these are microcontrollers with a DSP core for doing the ATRAC calculation. Please don't imagine that the ATRAC encoder operates as one huge logic operation of an ASIC. ATRAC encoding is still programmed in discrete, sequential steps, with lots of multiplies and adds. I would imagine the computing power (for performing ATRAC encoding) of the CXD-2652AR inside the MZ-R55 to be substantially less than a 500MHZ PIII (and it certainly runs a lot cooler!). Regards, Rick I thinks the PC has a performance problem due to the 'enormous' overhead of the OS and the fact that most encoders are programmed in C. Look, Eric uses Linux, an OS that is very stable and runs very efficient (I've still got a 486dx2 running it.). I think, that part of the problem is there! Cheers, Ralph - if the ATRAC DSP has an OS, it will probably be very very very small! -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
RE: MD: Sony's new Internet Audio Recording Interface
Rat rit: You make the assumption that the ATRAC ASIC in your R55 is doing math the same way your PIII does math, which is not the case. For its one task, the R55 is more powerful than your PIII. Rick was not assuming, he was asserting, that the ASIC contains a DSP core to execute the ATRAC algorithm. And I further assert (and I know because I have done it) that an FFT is performed on a DSP in a similar (but not identical) way to how it would be done on a Pentiuk. DSPs have special custom instructions to multiply and add in one operation, parallel instructions, zero overhead branching and RAM running at the CPU clock, which make them faster than general purpose CPUs at the same clock rate, but all these together don't amount to more than 5 times faster. My totally unsubstantiated guess is the R55's clock will be ~45 MHz (based on reading a number off a chip on an MZR35's circuit board). simon - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
RE: MD: Sony's new Internet Audio Recording Interface
Ralph Smeets wrote: I thinks the PC has a performance problem due to the 'enormous' overhead of the OS and the fact that most encoders are programmed in C. Most of the overhead of an OS is associated with input/output through multiple layers of device drivers/protocol stacks. If you have a computationally intensive algorithm, i/o is relatively unimportant and I would estimate the OS overhead as less than 1%. I've been using this NT machine for 3.5 hours now, and the task manager shows the system idle task has run for 3h33m CPU time. The total for ALL the other processes is about 3 minutes. Code written in C can easily be tens of times slower than hand written assembler, but is far more portable, and much easier to write. if the ATRAC DSP has an OS, it will probably be very very very small! For a dedicated processor, there is usually no need for an OS. simon - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: Ralph Smeets wrote: I thinks the PC has a performance problem due to the 'enormous' overhead of the OS and the fact that most encoders are programmed in C. Most of the overhead of an OS is associated with input/output through multiple layers of device drivers/protocol stacks. If you have a computationally intensive algorithm, i/o is relatively unimportant and I would estimate the OS overhead as less than 1%. I've been using this NT machine for 3.5 hours now, and the task manager shows the system idle task has run for 3h33m CPU time. The total for ALL the other processes is about 3 minutes. Hmm, what are you doing on that machine? I've never encoded something into an MP3 in all my live, so maybe I'm just stupid, but due to several 'architectural' problems with Windows, things run slower than on a Linux box. The Linux kernel fits on a floppy. The Windows 9x and Windows NT kernel need several floppy's. The memory footprint of these Windows systems is far larger than Linux, thus the need to use the SWAP space to. Add to that that most 'deamons' (little programs that are loaded into memory during the start-up of Windows) need more memory than the Linux equivalent. OS overhead is a real problem in this case. Code written in C can easily be tens of times slower than hand written assembler, but is far more portable, and much easier to write. if the ATRAC DSP has an OS, it will probably be very very very small! For a dedicated processor, there is usually no need for an OS. True! Cheers, Ralph - are we still on-topic? -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: Rat rit: You make the assumption that the ATRAC ASIC in your R55 is doing math the same way your PIII does math, which is not the case. For its one task, the R55 is more powerful than your PIII. Rick was not assuming, he was asserting, that the ASIC contains a DSP core to execute the ATRAC algorithm. And I further assert (and I know because I have done it) that an FFT is performed on a DSP in a similar (but not identical) way to how it would be done on a Pentiuk. DSPs have special custom instructions to multiply and add in one operation, parallel instructions, zero overhead branching and RAM running at the CPU clock, which make them faster than general purpose CPUs at the same clock rate, but all these together don't amount to more than 5 times faster. My totally unsubstantiated guess is the R55's clock will be ~45 MHz (based on reading a number off a chip on an MZR35's circuit board). Add to that the fact that most DSP cores I've seen, can do a load or store in one cycle. Some of them can load a value, do a calculation on it and write it back to memory. These things aren't (yet) possible on Pentiums. Cheers, Ralph -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: From: Simon Barnes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 08, 2000 12:16 PM Subject: RE: MD: Sony's new Internet Audio Recording Interface Rick was not assuming, he was asserting, that the ASIC contains a DSP core to execute the ATRAC algorithm. And I further assert (and I know because I have done it) that an FFT is performed on a DSP in a similar (but not identical) way to how it would be done on a Pentiuk. DSPs have special custom instructions to multiply and add in one operation, parallel instructions, zero overhead branching and RAM running at the CPU clock, which make them faster than general purpose CPUs at the same clock rate, but all these together don't amount to more than 5 times faster. My totally unsubstantiated guess is the R55's clock will be ~45 MHz (based on reading a number off a chip on an MZR35's circuit board). Ok, but my P3 has RAM running at 100MHz (soon to be 133MHz) - but for some operations I would expect the internal cache to be used which would obviously be much much faster. Even if we assume it *is* 5x faster using a dedicated DSP than the Pentium-based CPU, that is still only (based on your assumption of a 45MHz clock) a 225MHz pentium - well below standard for desktop system by todays standards. If you take into account some of the new MMX instructions plus various other enhancements being made to processors then I can't see why it would be a problem. Magic First: DSP cores normaly use SRAM. Ie, static RAM. This RAM normaly runs on the core speed. Writing and reading to this type of RAM can be done in one cycle. This RAM doesn't need a refresh. SDRAM is a dynamic RAM that runs on the same clock-base as the CPU. But it is also a dynamic RAM that needs to be refreshed. The refresh takes time! Second: Most DSP architecutures have a mechanism that split the memory into three or more parts. A program memory, a data-input and a data-output memory. This split garentees that you can fetch the next instruction with it's input execute the current instruction and write the output of the previous instruction in one cycle. (Ie do three things at the same time). The x86 has one memory for all. Ie, if you fetch an instruction, you can't write to the memory or read from another adres. Third: It's the OS in a Pentium class machine that does the cache prediction. YOU as a programmer can't influence it much. On a DSP, you have total control over the cache (if needed). There are many other reasons why the ATRAC DSP can do it operations more efficiently than a Pentium CPU. Most of them relate to the fact that the Pentium has to do a lot more other things! Cheers, Ralph -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Simon Barnes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 08, 2000 12:16 PM Subject: RE: MD: Sony's new Internet Audio Recording Interface Rick was not assuming, he was asserting, that the ASIC contains a DSP core to execute the ATRAC algorithm. And I further assert (and I know because I have done it) that an FFT is performed on a DSP in a similar (but not identical) way to how it would be done on a Pentiuk. DSPs have special custom instructions to multiply and add in one operation, parallel instructions, zero overhead branching and RAM running at the CPU clock, which make them faster than general purpose CPUs at the same clock rate, but all these together don't amount to more than 5 times faster. My totally unsubstantiated guess is the R55's clock will be ~45 MHz (based on reading a number off a chip on an MZR35's circuit board). Ok, but my P3 has RAM running at 100MHz (soon to be 133MHz) - but for some operations I would expect the internal cache to be used which would obviously be much much faster. Even if we assume it *is* 5x faster using a dedicated DSP than the Pentium-based CPU, that is still only (based on your assumption of a 45MHz clock) a 225MHz pentium - well below standard for desktop system by todays standards. If you take into account some of the new MMX instructions plus various other enhancements being made to processors then I can't see why it would be a problem. Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
RE: MD: Sony's new Internet Audio Recording Interface
Ralph Smeets wrote: has run for 3h33m CPU time. The total for ALL the other processes is about 3 minutes. Hmm, what are you doing on that machine? As little as possible ? Reading/writing endless MD emails ? to. Add to that that most 'deamons' (little programs that are loaded into memory during the start-up of Windows) need more memory than the Linux equivalent. OS overhead is a real problem in this case. I agree that OS's can have a considerable MEMORY overhead, and if you don't have enough, this can then affect the speed if you get into swapping, but an ATRAC algorithm would have a small working set (demand for memory), so I wouldn't expect the OS to make a big impact. I'm not intending to digress into a Linux/Windoze comparison. Yes, you need to buy enough memory to satisfy the demands of your OS to run the programs you want. Ralph - are we still on-topic? Barely; I suppose we're spinning around the feasability of executing ATRAC on a PC. Rat had suggested that a PC is 600 times too slow. I don't think that is the case. simon - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
RE: MD: Sony's new Internet Audio Recording Interface
Haha! Excellent - an employee of a MD manufacturing company telling us cool factual MD stuff on the list! Welcome Chee Soon. Any chance of a definitive answer for the Rat about ATRAC ASICs vs PIIIs and Athlons? And what about Aiwa's next generation of MD products? Cheers, Alan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Yip, Chee Soon SHQ Sent: 08 March 2000 00:26 To: '[EMAIL PROTECTED]' Subject: Re: MD: Sony's new Internet Audio Recording Interface You're missing another point: I guess that if you send data at 2X/3X/4X to the MD, it will have to spin faster while recording; that implies greater power consumptions, and higher accuracy, so modifications to the MD hardware must be done anyway, and a standalone device won't be very practical without a specific MD device that could handle this. And forget about having that in portables without prohibitively rising its price... You are right. Current generation of LSI can support ATRAC-ATRAC DUBBING/4X REC. During recording, the MD has to run a 2x CLV to maintain shock resistivity. Much redesign of hardware is needed. Cost wise, a double CLV pickup cost about 10 times the current single speed CLV type. cs [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: If that were the case, then you would be able to encode MP3 streams that sound as good as ATRAC 4 (which they do not) in real time on your desktop (which you cannot at this time). As I mentioned previously, a Pentium II running at 400MHz is capable of turning SPDIF into 128Kbps MP3 in real time, if it is not doing anything else. The particular machine in question is a 64Mb system with fast/wide SCSI (so, no bottleneck there), using LAME. 128Kbps MP3s do not sound nearly as good as ATRAC 4, so I have to say that the computational loads are not comparable. Well, FWIW, I can do realtime at 128, 192, and 256kbps with the 8hz-mp3 encoder on my Alpha (21164A, 533MHz, UW-SCSI), but that still doesn't mean that the computational load is "light" by any stretch. Hmmm, so here's my humble opinion. 1) The Alpha is about 4 times faster at the same clock-speed than a Pentium class CPU 2) ATRAC is dedicated hardware. Compare it to the 3D graphics interface in your PC. If you didn't have it, you wouldn't be able to sustain 70fps with your favourite 3D game. ATRAC has changed but not dramaticly after version 3.0. The CPU's in PC's have. There will be and there will come a time when CPU's can do the ATRAC encoding in real time. Maybee this time has already arrived? 3) Why is a 128kbit encoding faster than the 384kbit encoding? The data that needs to be trown away at 128kbit is 3 times more than at 384kbit. Cheers, Ralph - never decoded or encoded a MP3 in his live.. -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
On 6 Mar 2000, Stainless Steel Rat wrote: Hi, Don't want to stop an interesting thread, but... [...] | Yeh but you don't want to emulate an ATRAC chip, you wana encode data to | ATRAC standard natively on a PC using a PC processor software taking | advantage of chip specific features. Yes, and that requires many fast fourier transformations (FFTs) per second, which as I said before are slow on general purpose processors. ATRAC 4 in real time is just not going to happen on the desktop for a while for that reason. I guess Sony is never letting this to happen. I mean, to provide specifications in order to implement such a encoder. Neither Sony or others, I'd swear. You're missing another point: I guess that if you send data at 2X/3X/4X to the MD, it will have to spin faster while recording; that implies greater power consumptions, and higher accuracy, so modifications to the MD hardware must be done anyway, and a standalone device won't be very practical without a specific MD device that could handle this. And forget about having that in portables without prohibitively rising its price... So the point, being realistic is: When are vendors going to provide a MD that could take USB data and encode it at the fastest speeds that MD laser circuitry/servos etc. and the ATRAC ASICs could handle? I also think that the best market positioning for it will be an standalone, for-PC-users-intended MD deck. Something like the MDS-PC1... greets, *---(*)---**-- Francisco J. Montilla System Network administrator [EMAIL PROTECTED] irc: pukkaSevilleSpain INSFLUG (LiNUX) Coordinator: www.insflug.org - ftp.insflug.org - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
[EMAIL PROTECTED] wrote: On 6 Mar 2000, Stainless Steel Rat wrote: Hi, Don't want to stop an interesting thread, but... [...] | Yeh but you don't want to emulate an ATRAC chip, you wana encode data to | ATRAC standard natively on a PC using a PC processor software taking | advantage of chip specific features. Yes, and that requires many fast fourier transformations (FFTs) per second, which as I said before are slow on general purpose processors. ATRAC 4 in real time is just not going to happen on the desktop for a while for that reason. I guess Sony is never letting this to happen. I mean, to provide specifications in order to implement such a encoder. Neither Sony or others, I'd swear. You're missing another point: I guess that if you send data at 2X/3X/4X to the MD, it will have to spin faster while recording; that implies greater power consumptions, and higher accuracy, so modifications to the MD hardware must be done anyway, and a standalone device won't be very practical without a specific MD device that could handle this. And forget about having that in portables without prohibitively rising its price... Hmm... I don't know for recording, but I know that for reading, the disc spins at (least)! 4x. This in order to keep the 10s or more memory buffer filled! Cheers, Ralph -- === Ralph SmeetsFunctional Verification Centre Of Competence - CMG Voice: (+33) (0)4 76 58 44 46 STMicroelectronics Fax:(+33) (0)4 76 58 40 11 5, chem de la Dhuy Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN E-Mail: [EMAIL PROTECTED] FRANCE === "For many years, mankind lived just like the animals. And then something happened that unleashed the powers of our imagination: We learned to talk." -- Stephen Hawking, later used by Pink Floyd -- === - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
Hi, Two points on this rather lengthy thread-- AMD have just announced the release of a 1GHz Athlon CPU, and Intel are expected to announce a P3 at 1GHz very soon. If Rat thinks these monsters can't handle a well-written implementation of even R-Type Atrac what do you think is needed? Secondly I doubt we'll see Sony do a software ATRAC implementation of their algorithm as Sharp et al will probably reverse-engineer it for their chips, to solve their current ATRACs tendency to trash the sound into a load of snap, crackle and pops :-P Cheers, PrinceGaz -- "if it harms none, do what you will" Email: [EMAIL PROTECTED] Website: http://website.lineone.net/~princegaz/ ICQ: 36892193 Earn a minimum of $20 per hour by watching ads on the net! Visit http://www.bepaid.com/users.rhtml?REFID=10164669 - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
06 Mar 2000 21:35:42 -0500 Stainless Steel Rat [EMAIL PROTECTED] Wrote: | Yes, and that requires many fast fourier transformations (FFTs) per second, | which as I said before are slow on general purpose processors. ATRAC 4 in | real time is just not going to happen on the desktop for a while for that | reason. The FFT's are not the problem, as decoding MP3 is done in real time and the IFFT is computationally comparable to the FFT. The MP3 encoding process cannot be compared either as MPEG encoding is more complex then ATRAC do to the additional runlength encoding and huffman optimizations. The biggest problem with ATRAC in software is that the perceptual coding part isn't standardized, so whoever writes the code will have to model the end results based on far less research than anyone else with an ASIC implementation. Even if they were to write the soft ATRAC, there would be no improvement since no existing deck will take a precoded stream (a possible exception being the new 4x CD dubbing system). If someone were to release new hardware that solved this would anyone buy it? Just My Two Cents, RJ K - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Tue, 07 Mar 2000 | A fair comparison would be to encode at the same bitrate as ATRAC. 128kbps | is substantially less than ATRAC resulting in a heavier computatoinal | requirement as more optimisations need to be made. I would guestimate that the average desktop PC these days is comparable to my 400MHz Pentium II at work (this was a top of the line sytem a year ago). It cannot encode MP3 at 192Kbps or higher in real time. Therefore it is reasonably safe for me to say that the average desktop machine cannot manage ATRAC, which requires more computing power than MP3 at "near CD quality" bitrates, in real time, either. -- Rat [EMAIL PROTECTED]\ Warning: pregnant women, the elderly, and Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged PGP Key: at a key server near you! \ exposure to Happy Fun Ball. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "PrinceGaz" [EMAIL PROTECTED] on Tue, 07 Mar 2000 | AMD have just announced the release of a 1GHz Athlon CPU, and | Intel are expected to announce a P3 at 1GHz very soon. If Rat thinks | these monsters can't handle a well-written implementation of even | R-Type Atrac what do you think is needed? I did not say they could not handle it. The Motorola 6502 in an Apple ][+ could be used to implement ATRAC. The issue is whether or not desktop machines now can do it in real time. You are not going to see Athlon in *desktop* systems any time soon. | Secondly I doubt we'll see Sony do a software ATRAC implementation | of their algorithm as Sharp et al will probably reverse-engineer it | for their chips, to solve their current ATRACs tendency to trash the | sound into a load of snap, crackle and pops :-P I've had exactly one problem with my 702, and that was due to a defective original CD, not the recorder. So stop dissing Sharp, already. -- Rat [EMAIL PROTECTED]\ Ingredients of Happy Fun Ball include an Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to PGP Key: at a key server near you! \ Earth, presumably from outer space. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Tuesday, March 07, 2000 2:35 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface * Stories [EMAIL PROTECTED] on Mon, 06 Mar 2000 | Do you mean Compressing or Decompressing? snippage [...] | Yeh but you don't want to emulate an ATRAC chip, you wana encode data to | ATRAC standard natively on a PC using a PC processor software taking | advantage of chip specific features. Yes, and that requires many fast fourier transformations (FFTs) per second, which as I said before are slow on general purpose processors. ATRAC 4 in real time is just not going to happen on the desktop for a while for that reason. Strange - my old Acorn A3000 (RISC processor - 12MHz) seemed to cope happily with many FFT transforms. I had a program called FastFFT on my Acorn and it would perform some very complex calculations very quickly. I would expect a modern PC to leave it behind with ease. Winamp seems happy to do them too - it's how they make the little graphic EQ. Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Tuesday, March 07, 2000 2:33 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface * Eric Woudenberg [EMAIL PROTECTED] on Mon, 06 Mar 2000 | On what do you base this statement? My understanding of ATRAC (based | upon looking at an ATRAC decoder) is that the computational demands of | encoding ATRAC are similar to those for MP3. I would expect a software | ATRAC encoder to run about as fast as an MP3 encoder. If that were the case, then you would be able to encode MP3 streams that sound as good as ATRAC 4 (which they do not) in real time on your desktop (which you cannot at this time). If you use a good encoder and the *same* bitrate as ATRAC you get damn close! As I mentioned previously, a Pentium II running at 400MHz is capable of turning SPDIF into 128Kbps MP3 in real time, if it is not doing anything else. A fair comparison would be to encode at the same bitrate as ATRAC. 128kbps is substantially less than ATRAC resulting in a heavier computatoinal requirement as more optimisations need to be made. The particular machine in question is a 64Mb system with fast/wide SCSI (so, no bottleneck there), using LAME. 128Kbps MP3s do not sound nearly as good as ATRAC 4, so I have to say that the computational loads are not comparable. You have to compare like for like. You are not doing so. Your logic says that MP3 can't be comparable to ATRAC because if you compress audio to MP3 at half the bitrate of ATRAC it doesn't sound as good OF COURSE IT DOESN'T!!! But then I wouldn't expect MP3 at 128kbps to sound as good as MP3 at 256kbps either, so your logic would say even if I use the same encoder for both files they are not comparable. Did you remember to engage brain before making that comparison, or was it heat of the moment ? Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Tue, 07 Mar 2000 | Strange that - the Xing MP3 encoder managed to encode the whole of Elgar | Cello Concert (around 40 minutes of audio) in just under 5 minutes at | 160kbps. I'm using a P3 450MHz - 64Mb RAM. The Xing encoder is known to be only slightly better than the ISO reference implementation. That it, it sounds awful compared to either Fraunhauffer or LAME. [...] | I'm not sure where you got the idea that ATRAC encoding would require more | CPU power tham MP3 - surely this would depend on how the algo. was | implemented in the software! It depends more on the complexity of the algorithms. MPEG-1 Layer III was designed to be implemented in software; ATRAC was desgined to be implemented in an ASIC. | Speed does not always relate directly to the quality of the encoding | either - one MP3 encoder I had (I forget it's name) took 12 mins to | encode a 5min tune and the result was audibly worse than Xing at the same | bitrate which managed it in 15 seconds. Because the original ISO reference implementation has absolutely no assembly optimization in it. | I don't think you can assume the average desktop machine couldn't do it - it | would be down to how well the software implementation of ATRAC was written, | and that will depend on how good the programmer is. The issue is whether or not a desktop machine can handle the large number of FFTs that the ATRAC ASIC performs in real time. And the fact is, today's machines cannot. They lack the "hardware acceleration" chipset that exists in every MD recorder. -- Rat [EMAIL PROTECTED]\ Ingredients of Happy Fun Ball include an Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to PGP Key: at a key server near you! \ Earth, presumably from outer space. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
You're missing another point: I guess that if you send data at 2X/3X/4X to the MD, it will have to spin faster while recording; that implies greater power consumptions, and higher accuracy, so modifications to the MD hardware must be done anyway, and a standalone device won't be very practical without a specific MD device that could handle this. And forget about having that in portables without prohibitively rising its price... You are right. Current generation of LSI can support ATRAC-ATRAC DUBBING/4X REC. During recording, the MD has to run a 2x CLV to maintain shock resistivity. Much redesign of hardware is needed. Cost wise, a double CLV pickup cost about 10 times the current single speed CLV type. cs [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* Ralph Smeets [EMAIL PROTECTED] on Tue, 07 Mar 2000 | 1) The Alpha is about 4 times faster at the same clock-speed than a Pentium | class |CPU Depends on the Pentium. The ~533MHz Alpha EV67 is effectively about twice as fast as a 500MHz Pentium III Xeon (I got to play with one of Compaq's prototype "Wildfire" systems yesterday :). | 2) ATRAC is dedicated hardware. Compare it to the 3D graphics interface in |your PC. If you didn't have it, you wouldn't be able to sustain 70fps |with your favourite 3D game. I've been trying to say this all along, and I never made that analogy. Thank you. |ATRAC has changed but not dramaticly after version 3.0. The CPU's in |PC's have. There will be and there will come a time when CPU's can |do the ATRAC encoding in real time. Maybee this time has already |arrived? The changes are primarilly in the psychoacoustic model. And maybe in two or three years the average desktop machine will be powerful enough to handle ATRAC 4 (or whatever) in real time. | 3) Why is a 128kbit encoding faster than the 384kbit encoding? The |data that needs to be trown away at 128kbit is 3 times more than at |384kbit. Yep. -- Rat [EMAIL PROTECTED]\ Caution: Happy Fun Ball may suddenly Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds. PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* Edmund Wong [EMAIL PROTECTED] on Mon, 06 Mar 2000 | Bleem! does, in fact, emulate the MIPS CPU directly. Well, no: URL:http://207.71.8.31/about/FAQ.html There is no emulation of the MIPS R3000A in Bleem!. | It's the only way you can run code for another CPU architecture. And the | 33mhz MIPS CPU has nowhere *NEAR* the power of a P166. Now who is comparing clock speeds or RISC vs. CISC, hmm? :) | And a P200 will not be able to emulate the Playstation fast enough for | 3D games using a software renderer. A 166MHz Pentium with a good sound card and a 3D accelerator will be just barely fast enough to run Bleem! at a resolution equivalent to your TV set. This is how I drew my comparison. Eliminate comparable subsystems from the list, starting with the 3D accelerator vs. the GTE and GPU on the R3000A. What you have left when you are done is... nothing. So comparing a 166-200MHz Pentium to a 33.3MHz R3000A is not absurd at all. And no, we are not off topic. The topic at hand is emulating the ATRAC ASIC in software, in real time. This whole digression is intended to inform the list about just how difficult, or even impossible, that is. Bleem works as well as it does because there is analogous hardware in both a desktop game PC and a PlayStation. There is nothing analogous to the ATRAC ASIC in a MiniDisc player or recorder in any desktop PC. Oh, and for those wondering what the hoek is an "ASIC", it is an Application-Specific Integrated Circuit. That is, it is a semiconductor circuit designed to perform one specific task or a few related tasks. The emissions control computer in your car is an ASIC. -- Rat [EMAIL PROTECTED]\ When not in use, Happy Fun Ball should be Minion of Nathan - Nathan says Hi! \ returned to its special container and PGP Key: at a key server near you! \ kept under refrigeration. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* Eric Woudenberg [EMAIL PROTECTED] on Mon, 06 Mar 2000 | On what do you base this statement? My understanding of ATRAC (based | upon looking at an ATRAC decoder) is that the computational demands of | encoding ATRAC are similar to those for MP3. I would expect a software | ATRAC encoder to run about as fast as an MP3 encoder. If that were the case, then you would be able to encode MP3 streams that sound as good as ATRAC 4 (which they do not) in real time on your desktop (which you cannot at this time). As I mentioned previously, a Pentium II running at 400MHz is capable of turning SPDIF into 128Kbps MP3 in real time, if it is not doing anything else. The particular machine in question is a 64Mb system with fast/wide SCSI (so, no bottleneck there), using LAME. 128Kbps MP3s do not sound nearly as good as ATRAC 4, so I have to say that the computational loads are not comparable. -- Rat [EMAIL PROTECTED]\ When not in use, Happy Fun Ball should be Minion of Nathan - Nathan says Hi! \ returned to its special container and PGP Key: at a key server near you! \ kept under refrigeration. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* Stories [EMAIL PROTECTED] on Mon, 06 Mar 2000 | Do you mean Compressing or Decompressing? Encoding. It is technically not compressing. | If your talking about compression, what software do you use? LAME. | because theres a HUGE variation between different products. | My PIII-500 quite happily compressed a 2:30 wave @ 320kbs 44.1 mp3 in | ~30 seconds | while playing back mp3's. (Using Xing audiocatalist.) Playback is a negligible load on anything faster than a 233MHz Pentium. [...] | Yeh but you don't want to emulate an ATRAC chip, you wana encode data to | ATRAC standard natively on a PC using a PC processor software taking | advantage of chip specific features. Yes, and that requires many fast fourier transformations (FFTs) per second, which as I said before are slow on general purpose processors. ATRAC 4 in real time is just not going to happen on the desktop for a while for that reason. | Incidentally dose anyone know how MP3 ATRAC compare regarding acoustic | compression? *snrk* -- Rat [EMAIL PROTECTED]\ If Happy Fun Ball begins to smoke, get Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover PGP Key: at a key server near you! \ head. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
If that were the case, then you would be able to encode MP3 streams that sound as good as ATRAC 4 (which they do not) in real time on your desktop (which you cannot at this time). As I mentioned previously, a Pentium II running at 400MHz is capable of turning SPDIF into 128Kbps MP3 in real time, if it is not doing anything else. The particular machine in question is a 64Mb system with fast/wide SCSI (so, no bottleneck there), using LAME. 128Kbps MP3s do not sound nearly as good as ATRAC 4, so I have to say that the computational loads are not comparable. Well, FWIW, I can do realtime at 128, 192, and 256kbps with the 8hz-mp3 encoder on my Alpha (21164A, 533MHz, UW-SCSI), but that still doesn't mean that the computational load is "light" by any stretch. /Andrew - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
RE: MD: Sony's new Internet Audio Recording Interface
The Stainless Steel Rat wrote: because FFTs are much more complex than simple things like addition and multiplication. I suppose FFT's ARE fairly complex, although they are implemented as a load of additions and multiplications. I would estimate the ASIC in any MD player or recoder is effectively 300 to 600 times more powerful for its one task than any modern desktop PC out there. This looks like an unsubstantiated guess, and MY (unsubstantiated) guess is that he is overestimating by 1000 to 1 times. Without detailed knowledge of the algorithms involved, this is fairly idle speculation. simon - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
On what do you base this statement? My understanding of ATRAC (based upon looking at an ATRAC decoder) is that the computational demands of encoding ATRAC are similar to those for MP3. I would expect a software ATRAC encoder to run about as fast as an MP3 encoder. On that note, remember the whole thing with the legal nightmare that is the Sony Music Clip? That did encoding of ATRAC (albiet ATRAC3) in software. I remember reading somewhere (I think it was in a minidisc.org news update) that ATRAC3 can be easily transcoded into ATRAC1 (or was it the other way around?). I guess you would probably be able to encode ATRAC1, but Sony doesn't want that to happen - legal stuff and all. - Ed. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
A Pentium II at 400MHz can manage to convert to MPEG-I Layer III at 128Kbps in real time. It cannot handle significantly higher bitrates in real time. Do you mean Compressing or Decompressing? If your talking about compression, what software do you use? because theres a HUGE variation between different products. My PIII-500 quite happily compressed a 2:30 wave @ 320kbs 44.1 mp3 in ~30 seconds while playing back mp3's. (Using Xing audiocatalist.) So I shouldn't think a P-II - 400 is that much slower. Anyway my point is that it depends on how the software is written. This is the machine I have at work, and that is my experience with it. And as everyone knows, 128Kbps MP3 sucks compared to ATRAC 4. Again Different software, different results. Also going through a noisy analogue sounds card doesn't help matters. I find 128/44.1 mp3 fine (certainly just as good as Minidisc) when going through the same DAC (JE520) It takes an 80486 running at 33MHz to emulate a 1MHz Apple ][ accurately (or a fast '386 if the emulator is written entirely in hand-optimized assembly rather than C). It takes a Pentium running at about 130MHz to emulate a Genesis console accurately. It takes a Pentium running at 200MHz or so to emulate the 33MHz PlayStation accurately. Emulation requires *vastly* more power than the actual hardware itself. Yeh but you don't want to emulate an ATRAC chip, you wana encode data to ATRAC standard natively on a PC using a PC processor software taking advantage of chip specific features. Incidentally dose anyone know how MP3 ATRAC compare regarding acoustic compression? -- Matt - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stories [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 06, 2000 2:18 PM Subject: Re: MD: Sony's new Internet Audio Recording Interface A Pentium II at 400MHz can manage to convert to MPEG-I Layer III at 128Kbps in real time. It cannot handle significantly higher bitrates in real time. Do you mean Compressing or Decompressing? If your talking about compression, what software do you use? because theres a HUGE variation between different products. My PIII-500 quite happily compressed a 2:30 wave @ 320kbs 44.1 mp3 in ~30 seconds while playing back mp3's. (Using Xing audiocatalist.) So I shouldn't think a P-II - 400 is that much slower. Anyway my point is that it depends on how the software is written. Yes, and the efficiecy of the encoder. Fraunhoffer is much more efficient than Xing, but also much slower. The resulting MP3s are higher quality at the same bitrates. This is the machine I have at work, and that is my experience with it. And as everyone knows, 128Kbps MP3 sucks compared to ATRAC 4. Again Different software, different results. Also going through a noisy analogue sounds card doesn't help matters. I find 128/44.1 mp3 fine (certainly just as good as Minidisc) when going through the same DAC (JE520) Not sure what stereo system you use, but even on my cheap stereo I have by the bed, I can hear a difference between well encoded MP3 at 128kbps and MD. MD leaves MP3 well behind until you encode at at least 192kbps. Incidentally dose anyone know how MP3 ATRAC compare regarding acoustic compression? I've compared them quite a bit and I arrived that the conclusion that there is more difference in quality between different MP3 encoders than there is between ATRAC and MP3. I reckon Fraunhoffer IIs encoding at 224kbps is about the same as Sony ATRAC 4.5 (not type R). Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Sunday, March 05, 2000 6:13 AM Subject: Re: MD: Sony's new Internet Audio Recording Interface * "Magic" [EMAIL PROTECTED] on Sat, 04 Mar 2000 | The most obvious solution to this would be to put the ATRAC encoding on the | computer end. This means that only 1/5th of the data would need to be sent | down the USB interface. It also means that you would not be able to use this with any existing MD hardware, which makes it useless for the entirety of current MD owners in the world. No, you'd simply have the option to send either "ATRAC Encoded" or "SPDIF" down the line. This would make it compatible with external CD-Rs etc too. Besides, ATRAC encoding in software is *SLOW* (every MD recorder in the world has a specialized, dedicated ASIC for this purpose). Current desktop PC hardware is not powerful enough to encode ATRAC 4 in real time using a software encoder. So any savings you might get for compressing the data before transmitting will be lost in the compression process. You expect me to believe that a P200 can emulate an entire playstation system with software emulation but not handle something as simple as ATRAC? My P3-450 has no trouble encoding 10 minutes of audio into a 320kbps MP3 in about 20 seconds, so I think it would handle ATRAC in the background without any problem at all. You could get near-perfect recordings too. If the requirement for real-time was removed and the audio was pre-encoded before being sent to the MD, the ATRAC version would become almost irrelevant - just like commercially released MDs, the abolute maximum quality could be obtained from the available data bandwidth. If Sony were starting from scratch, this might make sense. Given that MD is an established market, it makes no sense at all. On the contrary, adding improvements and extra features to make it fit into the requirements of it's users could only strengthen its position in the marketplace. It would be far more detremental to *not* advance the technology and get left behind. It would become like the vinyl LP, with only some hard-core fans still using it. Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "PrinceGaz" [EMAIL PROTECTED] on Sun, 05 Mar 2000 | Are you quite certain of that, my rodent friend? I'm very much into | emulation of other hardware on my PC (everything from fairly recent | arcade hardware, back to Space Invaders, various home computers, and the | Psion organiser range) and I reckon a decent PC could encode ATRAC 4 or | 4.5 in real-time with no great difficulty. A Pentium II at 400MHz can manage to convert to MPEG-I Layer III at 128Kbps in real time. It cannot handle significantly higher bitrates in real time. This is the machine I have at work, and that is my experience with it. And as everyone knows, 128Kbps MP3 sucks compared to ATRAC 4. [...] | If youre suggesting that is less processor intensive than what that | little chip in your R55 or whatever does then I seriously doubt your | sanity :-) That is exactly what I am saying. Dedicated ASICs blow away the general purpose processor you find in desktop machines. They excel at their one task. A "decent PC" simply cannot compare with an ATRAC ASIC. It cannot perform the staggering quantity of accoustic FFTs required to encode in real time. The current generation of almost-GHz systems possibly could, but those almost qualify as low-end supercomputers. It takes an 80486 running at 33MHz to emulate a 1MHz Apple ][ accurately (or a fast '386 if the emulator is written entirely in hand-optimized assembly rather than C). It takes a Pentium running at about 130MHz to emulate a Genesis console accurately. It takes a Pentium running at 200MHz or so to emulate the 33MHz PlayStation accurately. Emulation requires *vastly* more power than the actual hardware itself. -- Rat [EMAIL PROTECTED]\ Caution: Happy Fun Ball may suddenly Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds. PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Sun, 05 Mar 2000 | No, you'd simply have the option to send either "ATRAC Encoded" or "SPDIF" | down the line. This would make it compatible with external CD-Rs etc too. But you cannot do that, without encapsulating the SPDIF signal in the same fashion as SCSI over USB... which is pig-slow, and requires yet another kind of data converter in the USB tail. This also assumes that your system is fast enough to convert audio to SPDIF in real time. [...] | You expect me to believe that a P200 can emulate an entire playstation | system with software emulation but not handle something as simple as ATRAC? You assume ATRAC is simple when it is infinitely more complex than a PlayStation console. See my previous post for more. -- Rat [EMAIL PROTECTED]\ Do not taunt Happy Fun Ball. Minion of Nathan - Nathan says Hi! \ PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Stainless Steel Rat [EMAIL PROTECTED] To: MD-L [EMAIL PROTECTED] Sent: Sunday, March 05, 2000 2:59 PM Subject: Re: MD: Sony's new Internet Audio Recording Interface * "Magic" [EMAIL PROTECTED] on Sun, 05 Mar 2000 | No, you'd simply have the option to send either "ATRAC Encoded" or "SPDIF" | down the line. This would make it compatible with external CD-Rs etc too. But you cannot do that, without encapsulating the SPDIF signal in the same fashion as SCSI over USB... which is pig-slow, and requires yet another kind of data converter in the USB tail. This also assumes that your system is fast enough to convert audio to SPDIF in real time. Encoding SPDIF is incredibly simple. The USB tail need be nothing more than a simple output module. All it needs to do is buffer a small amount of data being sent to it and regardless of format, output it via an LED. [...] | You expect me to believe that a P200 can emulate an entire playstation | system with software emulation but not handle something as simple as ATRAC? You assume ATRAC is simple when it is infinitely more complex than a PlayStation console. See my previous post for more. You are underestimating the complexity of the PSX. Granted the main CPU is only 33MHz, but there are also dedicated sound chips, video hardware, memory re-mapping, fpu emulation, emulation of controllers and interfaces of which the 33MHz CPU emulation is just a very small part. A 100MHz 486 can emulate te 33MHz CPU of the PSX in real time without any problem, but that is virtually useless without emulating the additional hardware. Open up a PSX - there's substantially more in there than a CPU and power supply. What we are talking about is emulating one chip which is not overly complex compared to a good few others. There is also no requirement to emulate the MD processor - we're not running "MinidiscOS" or anything, we're talking about emulating the *process* which is different. There is no reason why you couldn't write an ATRAC encoder that is 100% compatible with the chip-based version and have it run on a computer system. I think your main problem with seeing the possibilities here is that you think the PC should be emulating the ATRAC chip itself, whereas I am suggesting that all you do is produce a program that gives the same end result by whatever means. If you were writing a calculator program, would you try and write a program to emulate all the chips in the calculator, or would you just use the much faster functions built into your computers CPU? I know which I would do Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Sun, 05 Mar 2000 | Encoding SPDIF is incredibly simple. Encoding USB bulk data traffic is not simple. Look at usb-storage.c in the current Linux 2.3 kernel source tree sometime (and that is one of the simpler drivers :). On top of that, SPDIF over USB has to be managed in real time, which increases complexity by roughly an order of magnitude. I am not saying it is impossible; I am saying that it is expensive. [...] | You are underestimating the complexity of the PSX. No, you are underestimating the nature of Fast Fourier Transformations, which are complex math, and hideously slow to calculate in software on general purpose computing hardware like desktop PCs. Bleem! is not an emulator. Emulation is slow, I mean really slow, I mean slow like molassas flowing up hill, in Alaska, in winter. The way Bleem! functions, it does not translate PlayStation code to Windows code. It simply maps PlayStation system calls to DirectX and Windows API calls, so that most of the processing happens in hardware, not software. Keep in mind that the PSX core CPU is roughly as powerful as a 166-200MHz Pentium class processor (clock speed is utterly meaningless when comparing RISC to non-RISC architectures). There is no FFT engine in a desktop PC, so it would need to be emulated in software. Big slow down there. Just for yucks if you can, compare an old 80386 with and without an 80387 math co-processor. To save you the trouble, you will find that the '387 can perform floating point calculations upwards of a hundred times faster than the '386 can manage in software. You are looking at the same kind of performance hit for the FFTs, except even moreso because FFTs are much more complex than simple things like addition and multiplication. I would estimate the ASIC in any MD player or recoder is effectively 300 to 600 times more powerful for its one task than any modern desktop PC out there. -- Rat [EMAIL PROTECTED]\ Do not taunt Happy Fun Ball. Minion of Nathan - Nathan says Hi! \ PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
... Bleem! is not an emulator. Emulation is slow, I mean really slow, I mean slow like molassas flowing up hill, in Alaska, in winter. The way Bleem! functions, it does not translate PlayStation code to Windows code. It simply maps PlayStation system calls to DirectX and Windows API calls, so that most of the processing happens in hardware, not software. Keep in mind that the PSX core CPU is roughly as powerful as a 166-200MHz Pentium class processor (clock speed is utterly meaningless when comparing RISC to non-RISC architectures). First off, with regards to the RISC comment: Clock speed is utterly meaningless when comparing ANYTHING of a mildly different architecture. For example, comparing the 450mhz AMD K6-2 to a P3-450 using clock speed is utterly meaningless. They are both x86 architectures, and will run the exact same code. The P3 has a nicer FPU, the K6-2 has a good integer unit. They will run different code at different speeds. The whole RISC vs. CISC thing is way overrated. RISC is a design philosophy, not a magic technique which will make a CPU instantly 200% faster. A RISC CPU is *designed* to have a smaller number of instructions which have been heavily optimized. That said, I'd also like to point out that the 33mhz MIPS CPU used in the PSX does nothing but execute game code. It doesn't have to worry about operating systems, device drivers, memory protection, multitasking, networking, et al. Instead, it will execute game code. And game code. And game code. Bleem! does, in fact, emulate the MIPS CPU directly. It's the only way you can run code for another CPU architecture. What it DOES "map" to PC equivalents is the custom PSX chipset (consisting of 4 seperate chips, if memory serves correct) and the sound chipset. The emulator will tell the emulated CPU that this chipset exists and that you can access these chips directly, and then proceeds to execute the code. Rendering can be passed onto a 3D hardware accelerator this way. And the 33mhz MIPS CPU has nowhere *NEAR* the power of a P166. And a P200 will not be able to emulate the Playstation fast enough for 3D games using a software renderer. And a P200 will play Street Fighter Zero3 for the PSX at a speed which is, to borrow a quote from above, not unlike "molassas flowing up hill, in Alaska, in winter". But we're straying WAY off topic here. I just wanted to make some corrections. - Ed. - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: Eric Woudenberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 03, 2000 11:25 PM Subject: MD: Sony's new Internet Audio Recording Interface 3) Make it run at a special 4X or 8x S/PDIF rate, so that a portable MD player could compete in downloading convenience with an MP3 player. The most obvious solution to this would be to put the ATRAC encoding on the computer end. This means that only 1/5th of the data would need to be sent down the USB interface. If you kept the data rate the same, this would result in 5x recording! You can output CD data at 6x on USB (assuming no other hi-level hardware devices are in use on the USB line) so this would result in 30x record speed if the MD could keep up! Imagine... recording a 74minute disc in just over 2 minutes :o) Magic -- "Creativity is more a birthright than an acquisition, and the power of sound is wisdom and understanding applied to the power of vibration." Location : Portsmouth, England, UK Homepage : http://www.mattnet.freeserve.co.uk EMail : [EMAIL PROTECTED] - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
* "Magic" [EMAIL PROTECTED] on Sat, 04 Mar 2000 | The most obvious solution to this would be to put the ATRAC encoding on the | computer end. This means that only 1/5th of the data would need to be sent | down the USB interface. It also means that you would not be able to use this with any existing MD hardware, which makes it useless for the entirety of current MD owners in the world. Besides, ATRAC encoding in software is *SLOW* (every MD recorder in the world has a specialized, dedicated ASIC for this purpose). Current desktop PC hardware is not powerful enough to encode ATRAC 4 in real time using a software encoder. So any savings you might get for compressing the data before transmitting will be lost in the compression process. If Sony were starting from scratch, this might make sense. Given that MD is an established market, it makes no sense at all. -- Rat [EMAIL PROTECTED]\ Happy Fun Ball may stick to certain types Minion of Nathan - Nathan says Hi! \ of skin. PGP Key: at a key server near you! \ - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
From: "Stainless Steel Rat" [EMAIL PROTECTED] * "Magic" [EMAIL PROTECTED] on Sat, 04 Mar 2000 | The most obvious solution to this would be to put the ATRAC encoding on the | computer end. This means that only 1/5th of the data would need to be sent | down the USB interface. Besides, ATRAC encoding in software is *SLOW* (every MD recorder in the world has a specialized, dedicated ASIC for this purpose). Current desktop PC hardware is not powerful enough to encode ATRAC 4 in real time using a software encoder. So any savings you might get for compressing the data before transmitting will be lost in the compression process. Are you quite certain of that, my rodent friend? I'm very much into emulation of other hardware on my PC (everything from fairly recent arcade hardware, back to Space Invaders, various home computers, and the Psion organiser range) and I reckon a decent PC could encode ATRAC 4 or 4.5 in real-time with no great difficulty. My PC can happily (well okay the cpu is almost flat-out in this case) emulate a 68000cpu at 20MHz, a Z80 at 6MHz, a couple of proprietary sound chips, then send the sound waveform to my soundcard at 44.1KHz sample rate, convert the games' original video memory bitmap to something the video card can use at 60fps, all the while taking user input (movement and fire etc). If youre suggesting that is less processor intensive than what that little chip in your R55 or whatever does then I seriously doubt your sanity :-) Of course if your desktop PC *is* an original PC (8086 @ 4.77MHz) then you may be right, but a k6-3/450 with 128mb pc100 ram is frighteningly fast, I finally got the memory upgrade due to low prices currently and it's made it about 20% faster on a program that fitted entirely into the old 32mb just cos it's a faster memory type-- boy am I happy :-) Cheers, PrinceGaz -- "if it harms none, do what you will" Email: [EMAIL PROTECTED] Website: http://website.lineone.net/~princegaz/ ICQ: 36892193 Earn a minimum of $20 per hour by watching ads on the net! Visit http://www.bepaid.com/users.rhtml?REFID=10164669 - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
Re: MD: Sony's new Internet Audio Recording Interface
Is S/PDIF hard to generate? Computer audio chips tend to send/receive it right with pins on the main sound chip and CD/MD equipment also tends to have it integrated at the chip level (this is the most economical way to do it). So my guess is that it's no big deal, if Sony has designed a special chip. Alternatively, Crystal Semiconductor makes generic S/PDIF transmitter receiver chips. Make it run at a special 4X or 8x S/PDIF rate, so that a portable MD player could compete in downloading convenience with an MP3 player. 4X is no big deal if Sony designs their own chips (both in the interface and the MD). So far as I know, the highest speed that the Crystal chips run at is 96K (there's not a big market for higher speed yet), which would at least handle the 88.2K rate for 2X transfer. I think the fastest USB transfer rate would limit things to 4X or so... I'm hoping that the USB - MD interface is so successful that Sony starts putting it into new recorders at the chip level. That would allow them to produce USB-enabled MD recorders for little more than the price of the USB connector! If they did it at the chip level, maybe they could (in the future) revive MD data, so you could make the MD recorder do double duty. (Although MD data disks are expensive right now, its only because the market is extremely small compared to the audio market. If there was a large base of MD data equipment; they price would come down. As a matter of fact, since there's no "SCMS tax" on data disks, it could go even lower!) - To stop getting this list send a message containing just the word "unsubscribe" to [EMAIL PROTECTED]
