VC/DC version 0.1a released.

[OneThirty8]

I've just released an updated version of my VCD/MPEG player.

THIS PLAYER PLAYS:
(S)VCD
MPEG-1 and MPEG-2 program streams (*.mpg, *.mpeg)
MPEG-1 and MPEG-2 elementary video streams (*.m1v, *.m2v)
MPEG elementary audio streams (*.mp1, *.mp2, *.mp3)
Dreamcast Sofdec movies (*.sfd, untested and won't play audio)
Playstation2 pss movies (*.pss, barely tested and won't play audio--this may change)


I released a version of this player sometime last summer numbered 0.1. The current version is 0.1a.

New in VC/DC 0.1a:
-No longer has horrible sound.
-Support for ID3 tags in MP3 files.
-Fast-Forward actually works.
-You're now able to replay a VCD without opening your Dreamcast's lid by pressing Start.

Get at it here: http://www.storm-studios.net/onethirty8/vcdc.html

[Christuserloeser]

Nice release!

I released a version of this player sometime last summer numbered 0.1. The current version is 0.1a.

v0.1a ? This release should have deserved at least a 0.2, don't you think ?

[MapleBuster]

All this stuff getting released and I can't burn any of it

Thanks for the program anyway. I can't remember the name of the VCD player I used to have but this sounds much better judging by those specs.

Will audio work on the Mpeg Sofdec in the future or is that impossible ?

[OneThirty8]

Nice release!

I released a version of this player sometime last summer numbered 0.1. The current version is 0.1a.

v0.1a ? This release should have deserved at least a 0.2, don't you think ?

I thought about it, but I have a lot more that I wanted to implement that I haven't done. VCD menus are on my wish list, but I have a lot of documentation and source code to dig through to figure out how to make sense of the Playlist Descriptors and all that. I also want to support ac3 audio and sound in .pss files, but I haven't really gotten into that yet.

All this stuff getting released and I can't burn any of it

Thanks for the program anyway. I can't remember the name of the VCD player I used to have but this sounds much better judging by those specs.

Will audio work on the Mpeg Sofdec in the future or is that impossible ?

I won't say that it's impossible, but I'm not sure I'll get them to work well. Bero made a tool to convert sfd to mpg, so you might try that if you have some sofdec files you want to play on the Dreamcast.

[MapleBuster]

I upload sofdec files to a page and play them via the browser. Not the most efficient means. Converting to mpeg is probably the way to go.

AC3 support ! Oh yes. Keep going with that.

[Superstrider]

Sorry for reviving a dead topic, but I have some questions...

How do I burn this disc? Do I put the video files on the main disc or an ordinary VCD? Do you have a tutorial that I can reference?

[OneThirty8]

Sorry for reviving a dead topic, but I have some questions...

How do I burn this disc? Do I put the video files on the main disc or an ordinary VCD? Do you have a tutorial that I can reference?

You can put your video files on the main disc, a separate data CD-R, or author a VCD with Nero (or whatever program). As for burning the program as a self-booting CD, there are several methods availabe. BootDreams should be the easiest to use. Make sure you download the newest version of VC/DC--version 0.1a has much better sound than 0.1.

Also, don't expect great playback speed on every file. SVCD will probably be pretty horrible. Files that were encoded without B-frames will probably play back at least a few FPS too slowly, which is going to give you some stuttering audio. Keep your video resolution at 352x288 or smaller and use a VCD template in TMPGEnc if you can.

[DaMadFiddler]

I wonder if anything from this open-source project would help:

http://picard.exceed.hu/tcpmp/

It's a program I've used for a long time now on my Zodiac. It supports most modern formats (including h.264 and aac+), has a codec plugin architecture, etc. It doesn't have much in terms of a user interface, but it is very competent at decoding complex A/V streams on a low-spec device.

On my Zodiac, which has a 480x320 screen and a 200MHz ARM-derived processor, I have no problems with MPEG4 files at 1000Kbps or less, even at high resolutions (I usually rip my stuff at native DVD resolution) and audio sampling rates.

I don't *think* the code is too dependent on the system architecture or the Palm OS, since it (1) runs on most Palm devices and (2) was originally ported from a Windows Mobile project.

[OneThirty8]

I will take a look at it. I haven't been working on this at all lately, but that project sounds interesting.

[DaMadFiddler]

I will take a look at it. I haven't been working on this at all lately, but that project sounds interesting.

Have you had a chance to look at this at all? Is it something that may prove useful, or is the code too riddled with Palm OS eccentricities?

[OneThirty8]

I will take a look at it. I haven't been working on this at all lately, but that project sounds interesting.

Have you had a chance to look at this at all? Is it something that may prove useful, or is the code too riddled with Palm OS eccentricities?

I glanced at it for a minute or two. I didn't see any use of the libraries I'm using for decoding, so I'm inclined to think that a straight-up port of that program would be more worthwhile than trying to integrate anything from it into my existing program. Not that I'm promising to port it, but I'll probably play around with it a little bit and see what I can do with it when time permits.

[OneThirty8]

I know... old thread, and I don't know how many people are really using my program either--I honestly think DCDivX is probably better at giving a watchable result than VC/DC 0.1a.

So, I've been playing with this some more (no ETA on a new version, though), and I find that the VCD playback function has some pretty silly bugs. Just thought I'd mention that--you might get 2/3 of the way through a VCD and have it stop on you, so it's probably best to rip the MPEG files with VCDGear and play them as regular MPEG files. I haven't tried the player with .DAT files copied from VCD--the demuxer function isn't very smart, so it'll feed the extra data to the decoders and I think that will tend to confuse the decoders a bit and give you garbage output every now and again.

Next version should be much better. Some videos are probably still going to have audio stuttering, but I'll be including some features to attempt to minimize that, and I already rewrote the display and sound output code. But like I said, no ETA on a new version--it looks like I have to dig through the VCD-specific stuff and fix it (it is, after all, supposed to be a VCD player) and that's going to be a headache. I also have a couple of other projects that I've been promising a couple people that I'd work on, and I don't want to spend all of my free time on VC/DC alone...

[Christuserloeser]

Just stumbled across this media player: http://www.mplayerhq.hu/design7/info.html

- There's some ARM related code, originally developed for PDAs. Maybe it can be ported to take advantage of the Dreamcast's ARM... (That's what CRI's ADX/ADPCM format does, and what's used in their Sofdec video files).


Edit: Actually ADX takes advantage of the Dreamcast's hardware based ADPCM decoder. - Like OpenBoR does too btw...


Anyway, maybe the ARM code from MPlayer can be used with the Dreamcast's ARM, so the SH4 doesn't need to decode sound on top of the video... ?

[OneThirty8]

Just stumbled across this media player: http://www.mplayerhq.hu/design7/info.html

- There's some ARM related code, originally developed for PDAs. Maybe it can be ported to take advantage of the Dreamcast's ARM... (That's what CRI's ADX/ADPCM format does, and what's used in their Sofdec video files).


Edit: Actually ADX takes advantage of the Dreamcast's hardware based ADPCM decoder. - Like OpenBoR does too btw...


Anyway, maybe the ARM code from MPlayer can be used with the Dreamcast's ARM, so the SH4 doesn't need to decode sound on top of the video... ?

I don't think it would really work-- viewtopic.php?f=29&t=64180&hilit=decode+ogg

I think you're going to have trouble with that. The ARM is slow. Really slow. In theory, it's clocked at around 45MHz. It has no cache, and shares it's memory with the sound hardware itself. Thus, there are some serious bus contention issues, and the sound hardware frequently gets exclusive access to SRAM. SRAM is also very slow. In effect, the ARM runs at nothing like 45MHz. It's very, very slow. I don't think you're going to be able to decode a Vorbis stream on it.

The DC's ARM is quite (read: incredibly) slow -- even doing fairly simple tasks can be a huge PITA.

Complex tasks are likely to be a tremendous time sink, as well as (generally) very difficult to achieve an acceptable solution.

If those guys don't think an ogg decoder running on the ARM is feasible, I'm not going to even bother trying to use it for mp3 decoding. You'll be surprised when I release the next VC/DC (I'm working on rewriting the very-buggy VCD routines right now). I've changed quite a few things under the hood, and playback is much improved. I don't think it'll ever play SVCD perfectly, but I'm pretty happy with how well it plays VCD streams.

I'll look into the ADX bit, though. If the sound hardware will decompress ADX ADPCM (is it the same as what wav2adpcm generates? I'll have to compare them.) then that will be pretty easy to implement if I decide I want to bother with decoding audio on game-system-specific files. PSS audio is easy too as it's just linear PCM (or, according to La Cible's source code for lvfdc, it also can use an ADPCM format, so support would be limited). Those aren't really high priority, though. AC3/A52 would be nice too.

[Christuserloeser]

I think it's possible that it's faster than people assume, considering the GBA has the same CPU but clocked at 16 MHz instead of 25 like on DC. Also, I remember that Heliophobe used the ARM to emulate the SMS sound in SMEG at one point.

Here's something interesting:

viewtopic.php?p=241423#p241423

2) for the speed I don't really know but this part from this doc (http://hitmen.c02.at/files/docs/dc/aica_v08.txt) said that :
// ----------------------------------------------------------------------------
// 0x28a8 - ARMClock - GUESS
+--------------+
| 31-8 | 7-0 |
| n/a | mhz |
+--------------+

mhz: sets the speed of the ARM7 CPU in MHz steps.
00 = 1 MHz, 24 = 25 MHz
don't try to overclock the ARM7 it may get burned or something.


// ----------------------------------------------------------------------------

[OneThirty8]

I really don't think it's worth it for this player. You have no idea how long it would take me to even begin to implement something like that on the ARM--I don't really have enough of an understanding of how the ARM and SH-4 talk to each other. I think that the audio system I have in the version currently in development solves the worst of the problems I was having.

[Christuserloeser]

No prob, that's okay. I've been looking for some info on the ARM / AICA and ADPCM lately so that's all that I can think about atm ^ ^

I'll look into the ADX bit, though. If the sound hardware will decompress ADX ADPCM (is it the same as what wav2adpcm generates? I'll have to compare them.) then that will be pretty easy to implement if I decide I want to bother with decoding audio on game-system-specific files. PSS audio is easy too as it's just linear PCM (or, according to La Cible's source code for lvfdc, it also can use an ADPCM format, so support would be limited). Those aren't really high priority, though. AC3/A52 would be nice too.

Some links I collected:

CRI's ADX ADPCM file format used by MANY Dreamcast games:
http://en.wikipedia.org/wiki/ADX_(file_format)
http://wiki.multimedia.cx/index.php?title=CRI_ADX_ADPCM
http://web.archive.org/web/200111281606 ... _adx_e.htm

BERO's WAV2ADX converter incl. source:
wav2adx download (2001/01/25) with src:
http://www.geocities.co.jp/Playtown/200 ... av2adx.lzh (right-click and save as...)

BERO's ADX2WAV converter incl. source:
adx2wav download (update 2001/01/25) with src:
http://www.geocities.co.jp/Playtown/200 ... 2wav02.lzh (right-click and save as...)

[OneThirty8]

I have adx2wav. I just haven't compared it to wav2adpcm to see if the format is different. It won't help with mp1/2/3 audio, but it's worth looking at for Sofdec files. But thanks.

[Christuserloeser]

No prob.

More information about the Dreamcast's AICA (in Japanese):
http://www.geocities.co.jp/SiliconValle ... sound.html (Google Translation)
...plus some kind of a sound driver: http://www.geocities.co.jp/SiliconValle ... v_test.zip
...probably also used for this game: http://www.geocities.co.jp/siliconvalle ... ka_src.zip


WAV2ADPCM (original version) download:
http://www.geocities.co.jp/SiliconValle ... 2adpcm.zip

...and a newer version of Bero's ADPCM source, with rounding errors removed:
http://palm.projekt-base.de/wiki/upload/Pa1Lib_SDK.zip

Modified by Daniel Morais ( daniel at morais.com ) on 09/09/2002 :

- better precision when encoding ( removed rounding errors )

- 4 bit nibbles are swapped as it seem it is the format used

- can now be used on big and little endian computers

[OneThirty8]

Thanks again.

Actually, if the Dreamcast's hardware can decode ADX ADPCM samples, I probably don't need Bero's code in my actual program. I'll just make a copy of the sound streaming functions from KOS to let me use ADPCM audio on a streaming channel and feed it ADPCM data instead of decoded PCM samples. But it will be helpful to take a look at that modified version of the code--I looked at wav2adpcm's adpcm->pcm conversion function and adx2wav's adpcm->pcm conversion function, and the functions look similar but not the same. So the modified version might tell me if we're actually dealing with the same thing or not.

But I'm done looking at source code this evening. I'm trying to implement some stuff in a way that will be functionally similar to a xine plugin I've been looking at, but looking at that particular xine plugin, and then the library that the plugin uses, and then the ISO9660 filesystem library that is constantly referred to in places where I can't understand why the program should be reading from disc at all... I've got a monster of a headache. But I've figured out what I wanted to know. Thankfully, the Dreamcast only has one possible set of hardware to deal with, which will make my implementation of the same 'thing' a much simpler task. I know how to find the data I want, I know what data I can safely throw away, and I'm only going to deal with one set of this stuff at a time whereas that xine plugin seems to be allowing for multiple instances at one time (which would be impossible on the Dreamcast).

Sorry--felt the need to vent. And sorry if it's hard to understand what I'm talking about in the last paragraph. What I'm working on is probably not going to be finished when I release a new version, so I don't want to hype it up too much.

I'm going to bed.