Dreamcast Media Center

[PH3NOM]

Dreamcast Media Center.

I have been working hard on this project, aiming to achieve the greatest Multi-Media application for the Sega Dreamcast console.

Beta 1 Has been released for public testing, check out the homepage for this project:
https://sites.google.com/site/dreamcastmediacenter/

EDIT:
With MegaUpload going down, I have uploaded the beta here:

dcmc_beta1_8-21-2011.rar

(2.56 MiB) Downloaded 834 times

This application is built from the ground up, not using code from previous DC media players, or even XBMC,
although the GUI does resemble XBMC PH3:HD skin

The media libraries used are the most recent builds, to date.

Current Codec/Format Support:

Videos:
-LibXviD (.avi)
-LibMPEG2 (.m1v/.m2v)

Music: Up to *6ch **96kHz supported
-LibMPG123 ( .mp2/.mp3 )
-LibOGGVorbis ( .ogg )
-LibFAAD ( .mp4/.m4a/.aac )
-LibA52 ( .ac3 )
-LibFLAC ( .flac )
-Wave ( .wav )

-Playlists ( .m3u/.pls )

(*6ch Audio streams supported by LibFAAD and LibA52 decoders only )
(**96kHz supported encoders only )

Photos: ( Limited to VRAM being used by GUI, currently 1024x1024 maximum resolution )
- Jpg
- Png
- Pvr

Apps:
- Execute other ( un-scrambled) binaries

PM me if you can help with the project!

Screenshots:

Main Menu


File Browser ( photos )


During Audio Playback

[Stryfe]

What are the supported, or targeted for being supported, formats?

Mp3 is a given I suppose, and maybe ogg...

What about midi, chiptunes, or mod tracker formats?

[Basil]

I have some spare time and blank cds to i'd like to test it .

[Neoblast]

Awesome, so this was what you were working on huh?

Count on me for the beta testing

EDIT: I have both BBA and SD card to test it.

Does this mean you libdcdivx is finished and working?

[Chilly Willy]

Add FLAC to the audio codecs. That can be 6 ch as well, and is VERY popular right now for lossless backup of CDs. All my CDs are dumped as FLACs. AC3 6 ch from DVDs is commonly saved as FLAC, not AC3; that's because FLAC is more common on audio players than AC3. For example, if you're a filthy stinking pirate ( ), lots of SACD rips are all posted as FLAC.

[PH3NOM]

What are the supported, or targeted for being supported, formats?

Mp3 is a given I suppose, and maybe ogg...

What about midi, chiptunes, or mod tracker formats?

Sorry, I didn't have much time before work this morning: Post updated.
More audio formats are planned, any recommendations will be considered. I imagine the formats you mentioned will be simple to implement.

Add FLAC to the audio codecs. That can be 6 ch as well, and is VERY popular right now for lossless backup of CDs. All my CDs are dumped as FLACs. AC3 6 ch from DVDs is commonly saved as FLAC, not AC3; that's because FLAC is more common on audio players than AC3. For example, if you're a filthy stinking pirate ( ), lots of SACD rips are all posted as FLAC.

Yes!
LibFLAC is ported. Currently working on decoder application.

Although, in terms of audio decoding on the Dreamcast, the primary limitation is input bandwidth.
The GD-Rom can read about 1.5Mbps Max? from a CD-R, about the rate of CDDA.
This would be fine for stereo flac, but probably not 6-ch.
The SD can read about 640kbps max? I dont think it could stream Flac.

Awesome, so this was what you were working on huh?

Count on me for the beta testing

EDIT: I have both BBA and SD card to test it.

Does this mean you libdcdivx is finished and working?

Good! I will send you a PM tomorrow.
And to answer your question... Yes and No... XviD-DC is working but not finished!

[Neoblast]

All right looking forward to it then. It sure looks promising.
Using biosfont is a wise decision as well...

[Basil]

I'd like to see at this time :
musepack audio coded added - it's open source.
sd card support - it's really getting very popular nowadays.
any thoughts about x264 ?

I have both BBA and SD card to test it.

me too, me too .

[Anthony817]

This is amazing news! Keep us updated.

[Chilly Willy]

Add FLAC to the audio codecs. That can be 6 ch as well, and is VERY popular right now for lossless backup of CDs. All my CDs are dumped as FLACs. AC3 6 ch from DVDs is commonly saved as FLAC, not AC3; that's because FLAC is more common on audio players than AC3. For example, if you're a filthy stinking pirate ( ), lots of SACD rips are all posted as FLAC.

Yes!
LibFLAC is ported. Currently working on decoder application.

Although, in terms of audio decoding on the Dreamcast, the primary limitation is input bandwidth.
The GD-Rom can read about 1.5Mbps Max? from a CD-R, about the rate of CDDA.
This would be fine for stereo flac, but probably not 6-ch.
The SD can read about 640kbps max? I dont think it could stream Flac.

Hmm - isn't the DC GDROM 12X CAV? That would give a data rate of 1.8 MBytes per second (12 * 150 KB/sec). That should more than cover 96kHz 24-bit 6 channel FLAC.

I've never tested the throughput from the CD, but it loads Doom data pretty fast.

By the way, I have an SD adapter coming in the mail... hopefully it will be here soon.

[PH3NOM]

Add FLAC to the audio codecs. That can be 6 ch as well, and is VERY popular right now for lossless backup of CDs. All my CDs are dumped as FLACs. AC3 6 ch from DVDs is commonly saved as FLAC, not AC3; that's because FLAC is more common on audio players than AC3. For example, if you're a filthy stinking pirate ( ), lots of SACD rips are all posted as FLAC.

Yes!
LibFLAC is ported. Currently working on decoder application.

Although, in terms of audio decoding on the Dreamcast, the primary limitation is input bandwidth.
The GD-Rom can read about 1.5Mbps Max? from a CD-R, about the rate of CDDA.
This would be fine for stereo flac, but probably not 6-ch.
The SD can read about 640kbps max? I dont think it could stream Flac.

Hmm - isn't the DC GDROM 12X CAV? That would give a data rate of 1.8 MBytes per second (12 * 150 KB/sec). That should more than cover 96kHz 24-bit 6 channel FLAC.

I've never tested the throughput from the CD, but it loads Doom data pretty fast.

By the way, I have an SD adapter coming in the mail... hopefully it will be here soon.

1.8Mbytes would be the Maximum speed ( outer sectors of CD-Rom )
Inner sectors would be slower.

Sorry man, check your math again.
I dont know what kind of FLAC files you have?
I have some vinyl 96kHz 24-bit Stereo FLAC rips that are average +2400kb/s.
Theres no way 6-ch would meet the data rate limitations....

BTW Neoblast is helping me get a version of k:os with SD support
I just need someone to donate me an SD reader;-)

I'd like to see at this time :
musepack audio coded added - it's open source.
sd card support - it's really getting very popular nowadays.
any thoughts about x264 ?

Yeah, I have wanted to get a x264 decoder working for DC.
Problem is, the only open source x264 decoder i know of is a part of ffmpeg.
To extract the x264 decoder from ffmpeg would be a nightmare.
I have compiled a minimalistic build of ffmpeg for dc k:os, but so far the sample decoder is crashing on DC after opening the x264 codec.
I have spoke with Multimedia-Mike about ffmpeg on dc, but I haven't heard back so for now this idea is on freeze.

About musepack, if I get some time, ill see if i can dig up the source code...

[Chilly Willy]

1.8Mbytes would be the Maximum speed ( outer sectors of CD-Rom )
Inner sectors would be slower.

Sorry man, check your math again.
I dont know what kind of FLAC files you have?
I have some vinyl 96kHz 24-bit Stereo FLAC rips that are average +2400kb/s.
Theres no way 6-ch would meet the data rate limitations....

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!

BTW Neoblast is helping me get a version of k:os with SD support
I just need someone to donate me an SD reader;-)

I just got mine in the mail today... maybe one of the folks here who has had theirs for a while can make a thread on the basics of using the SD adapter... how to make the SD ISO images, how to launch them, how to access the SD inside an executable... that sort of thing. If no one has made that thread by the time I figure that out myself, I'll make the thread.

any thoughts about x264 ?

Yeah, I have wanted to get a x264 decoder working for DC.
Problem is, the only open source x264 decoder i know of is a part of ffmpeg.
To extract the x264 decoder from ffmpeg would be a nightmare.
I have compiled a minimalistic build of ffmpeg for dc k:os, but so far the sample decoder is crashing on DC after opening the x264 codec.
I have spoke with Multimedia-Mike about ffmpeg on dc, but I haven't heard back so for now this idea is on freeze.

h.264 decoding is too intensive for the DC... not unless you make something like 160x120 15Hz video. No PS2 player handles it, and even the XBox has trouble decoding it.

[Neoblast]

I guess I'll have to make a thread about it soon but am in the middle of my exams period, with the kos I use it's in the vfs so with "/sd" is enough and works like a charm.

You can get it here:
svn://emuforge.com/kos
svn://emuforge.com/kosports

I really think sd support should be in the official kos svn repository...

It's the version we use for our projects ( emuforge & IberDC ) right now and has sd support.

Basically it's a heavily improved and merged with kos version of the old libsddc based on fatfs lib based on the initial port by j0d1m.

SD iso images are only for dreamshell to use ( allows you to use homebrew cd images and load them in dreamshell as if you put an actual cd on the DC, loaded from the sd card which iirc supports sdhc up to 32GB) and you can make them with the isomake program they have on their site which basically makes a standard iso out of a folder and hacks the binary's LBA to zero.

[Chilly Willy]

Okay, if /sd is in the current KOS I shouldn't have a problem using it. As to using the SD, I'm not very familiar with DreamShell. I just got the SD loaded v4.0 beta 4 and burned the CD. It loads fine from my SD card, an 8GB MicroSDHC. Weird thing... the new SD adapters use a different USB SD reader than in the photos... he's now using a HEYU SD/SDHC/MicroSD USB 2.0 reader that has a MicroSD slot as well as the more standard SD slot... which is good because I can't insert a card into the normal slot - the card won't go in all the way regardless of orientation.

DreamShell seems to exit to whatever shell they run it from for almost any action, and uses the mouse instead of the controller if found (INSTEAD OF rather than IN ADDITION TO). I did manage to run DcPlaya SD Edition, which worked fine. Guess I've got to find more SDISOs of stuff now. Maybe a sticky thread with links to SDISOs (not commercial games, of course, just homebrew) could be started.

[Eviltaco64X]

The dream, it's still going!

[Chilly Willy]

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!

[PH3NOM]

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!
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?
And, to be perfectly clear, 6ch audio is down-mixed to stereo ( in software ) before sending the samples to the SPU.

any thoughts about x264 ?

h.264 decoding is too intensive for the DC... not unless you make something like 160x120 15Hz video. No PS2 player handles it, and even the XBox has trouble decoding it.

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?

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...

[Chilly Willy]

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.

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.

[Neoblast]

There's however this one issue with dreamshell, in the case you want to load a binary, you can't. And it's a pain to make an iso everytime you want to load a different version of a binary ( I use bba for that but not everyone has one ).

DCLOAD a dctool need a revision, they're way too slow. I think removing some controls and check functions, would make it like 5x or 6x times faster which wouldn't produce any lag in dmc ( using bba ), but maybe data wouldn't be sent ok sometimes. Using the bba should be faster than it is... so far it's slower than the SD.

When using dctool/load 1.0.4....

You would have to either make an iso to load a bin from dreamshell, or use the only bin loader for the sd so far, chui's sd loader, simplistic, fast and realiable.

This dmc would have no problem loading bins and isos if implemented, I tried laoding bins form pc so i don't see why it wouldn't work for bins on sd.

I still think a config file to tell dmc where to load the files would be the best option.
In my case I would either load them from sd, or pc ( this one being slower ).
Burning cds with all these new options isn't confortable.

Rumours are that in the new dreamshell version, there will be GDI and CDI support.

[PH3NOM]

DCLOAD a dctool need a revision, they're way too slow. I think removing some controls and check functions, would make it like 5x or 6x times faster which wouldn't produce any lag in dmc ( using bba )

Im not sure what you are saying here.
I think you are saying that DCMC will be faster if I remove the controller input / gui process?
Well, the controller input / GUI drawing is already handled in a separate thread from the decoders.
It shouldn't have any impact.

I still think a config file to tell dmc where to load the files would be the best option.
In my case I would either load them from sd, or pc ( this one being slower ).
Burning cds with all these new options isn't confortable

And, your just referring to the GUI textures, right?
You got the last build I sent you, loading GUI from romdisk, right?
The only reason to allow for GUI textures outside of the romdisk would be to allow the user to customize the GUI.

Just wait, I will have an SD-Enabled build soon enough!

EDIT:
I have done a full checkout of svn://emuforge.com/kos successfully
But trying to grab svn://emuforge.com/kos fails:

Code: Select all

svn: In directory 'kosports/libpng-1.2.8'
svn: 'kosports/libpng-1.2.8/.svn/tmp/text-base/Makefile.svn-base' has unsupported
special file type 'include'