Chilly Willy wrote:
You're confusing kilo BITS per second with kilo BYTES per second. 96000*3*6 = 1728000 bytes per sec. That's 96kHz 24-bit 6 channel audio, uncompressed. If you have 48kHz samples, it will be half that. If they are 16-bit samples, it's 2/3 of THAT. Now add 30% compression from FLAC. I know the 1.8MB/sec I mentioned is the top speed, but most of the time you won't need anything close to it. Check the math!
I guess I was misinformed.
Then it seems the main limitation on a CD would be storage size. Audio at that rate can get big!
Right... 600MB of FLAC is not much better than plain CDDA.
It would be less an issue for SD, but SD has MUCH lower throughput. FLAC should be fine for plain CDDA on SD - 44100Hz 16-bit stereo samples is just 176400 bytes per second (raw). So FLAC rips of CDs should play off SD, but SACD rips may or may not be possible off the CD depending on exactly what rate and sample size is used.
Next Ill try out some 96kHz samples to see how the DC's SPU handles it!
Hopefully software re-sampling wouldn't be necessary. But if it is, 48kHz would be the re-sample rate, or should it be 44.1kHz for DC?
Err - from the formula used to set the sample rate, it seems AICA plays at 44.1kHz, and the sample is resampled in hardware to that rate. I have no idea how AICA's resampling would sound for something like that. I guess you'll have to try it and see. 48 to 44.1 shouldn't be a problem.
And, to be perfectly clear, 6ch audio is down-mixed to stereo ( in software ) before sending the samples to the SPU.
There are a number of different down-mix formulas used by different players to allow simple mixing, or Dolby mixing, Dolby Pro mixing, etc. You'll probably want to check that out... maybe make it an option the user can set.
Yeah, even with simplistic encoding, x264 requires relatively massive CPU.
This makes me wonder how cell phones have been doing it for years.
I had a Sony Ericsson w580i back in 2006 that could handle 320x240 mp4, and its CPU was slower than the DC's.
I tend to think they use a dedicated chip for video decoding?
Yep! Dedicated hardware chip for decoding mpeg2/4 is how they do it. Google has been pushing for hardware companies to also handle vp8/webm. It's much like the hardware support for different audio codecs on old phones and digital audio players... some handled mp3/wma, but not ogg.
Chilly Willy wrote:
SD really makes testing easier... no more burning endless CDRs. I now have just one CDR that boots DreamShell, and from there I can run stuff off the SD card. Nice!
I smell an abstraction of the SD-ISO loader implemented into my project...
Now, to get my hands on an SD-Reader...
I followed this guide:http://www.dcemu.co.uk/vbulletin/thread ... from-China
If you notice my posts (I'm JLF65 over there), it cost me a total of $26.14 USD and took almost 7 weeks, but I'm happy with how it turned out. I'm using an 8GB MicroSDHC card in the adapter, with no problems so far. I'm currently ripping my Sonic Adventure disc in DreamShell to the SD card. I'll probably rip a number of my game discs to see if they work so I can cut back on wear on the drive. I already made an SDISO for my Doom port... the SD is noticeably slower than the CD drive but I like the lack of grinding on the drive.