Request: Help with MCF-CD DShow filter

[Koepi]

Asking ahead soft to support this would be indeed a good idea

and don't get me wrong, I don't want to start a war, I just read the posts above as:
Now that we've successfully tested that it works, let's progress with MCF-CD (and forget about the general case).

If this isn't the case, I apologize, that was just what I understood.

I can't see why using some fancy header-copies for stability improvement with other formats than MCF is unnessecary.

Can't it be developed as a real general pseudo-standard? Or other way around, can you point me to some reading where I can find informations about what's _so_ different about MCF that it needs special treatment (other than avi, ogg, asf, wmv,...) on this CD type?

I think this format makes sense and is useful for every format available.

Believe me, I'm not trying to start a war here, nor would I like to see something like that starting about it.

I'm just a little sad that noone seems to share my point of view :-/

This will be my last post about this issue, as I'm more or less repeating myself over and over again.

If you want to lock it to MCF, just do so. If you don't want to lock it, it's way better and many people would be grateful to use it with whatever they like.

My last 2 cents

Koepi

[Koepi]

avi,

i just found your PM, maybe you can switch on your ICQ?

Regards,
Koepi

Originally posted by Koepi
[B]Hm, do I understand it right, it's going to be for MCF only?

No, misunderstanding. In fact, we are talking about two completely different things now :

1. A general Mode 2 Form 2 burning tool and DirectShowFilter, call it More-CD or EVCD or whatever, allowing you to burn and read all kinds of data to CD, including Ogg files. If CD is scratched you will likely loose some data, but remember Ogg is quite forgiving here, including its header, as it was designed for streaming also.

2. A specific MCF-CD data structure, being based on mode 2 form 2, but with enhanced security as we try to write the MCF headers in a different mode to avoid format corruption. This is necessary as the MCF header is a bit more complex compared to Ogg, and we fear the file might be unreadable if the header is broken. I am not sure if this could be done for Ogg also, but please accept the MCF dev team will not do it. Of course, the sources and everything are open, dont forget MCF is a L-GPL Project.

[ingoralfblum]

I see, that there's some talk about Ingo's version. But there is no Ingo's version, at least not a single one.

At first I experimented with reading raw mode 2 or xa form 2 tracks. This is what the two test programs do: simply read and write entire tracks.

Then I created a DirectShow filter, that reads a link file from an ISO filesystem. This link file contains a protected part of a media file an the track number, which indicates where the rest of the media file is found (as mode 2 for example). This is what the Mode2CDReaderFilter does (in the MediaXW Base package).

Last I found, that reading the CD directly seems not the right solution, because that worked only on NT based systems (NT, 2K, XP). This lead to the RIFFCDXAReaderFilter (in the MediaXW AVI package), which simply reads the data part of a RIFFCDXA file. (And that in a very dumb manner, because initial empty sectors are not skipped and the file is directly read from disk instead of another upstream reader filter).

Additionally I never had MCF in mind, when I played around with it. This is simply a misunderstanding, because of the information about it on the MCF site. When you talk about MCF-CD, this is clearly only Tronic's version.

Regards,

Ingo

[int 21h]

It seems to me developers are more in a posistion to get some good ground work done through the general 800mb image tool and DS filter, and then use that experience on the MCF specific cases. I also think that perhaps the DS filter should just be made as general as possible, sending the stripped file to the regular renderer for the dirty work. If MCF specific things need to be done, IMO, they should be done in the MCF DirectShow filter.

Was the SVCD/VCD thing fixxed so that this can co-exist with it?

[DeXT]

@oddball: yes it's possible to put any name in the file, the only problem is, since my little tool does not support Joliet, you must use a valid ISO-9660 Level 2 filename (i.e. 31 chars max, uppercase, only one extension allowed). Due to this and the fact the files are being read as RIFF/CDXA I chose to leave the original VCD names, but I'll improve this in future.

@Koepi: this time you got me wrong No MCF-CD is not for MCF content only, in fact it is in no way related to MCF, it's just an extension to the ISO Bridge M2F2 format which solves some of its limitations. Apart from this I'll maintain a generic Mode2 Form2 CD creation utility, very similar to the current one. You'll be able to use any of them but I think you'll want to use MCF-CD since it's better. Once the MCF-CD DS filters are installed it's all transparent to the user.

@ingo: thank you very much for your notes. Now I can see things a bit more clear. This idea about having a link file with all the protected stuff and the movie data in a separate one is very interesting. I guess I should discuss this with Tronic so we can have the best MCF-CD implementation. My goal is to make a MCF-CD test tool that is suitable for the MCF team so you can start doing real life tests with it. So I'm open to any idea from the MCF team.

@int 21h: the MCF-CD and the MCF DS filter are two separate ones. MCF-CD will read and parse the file off the CD, which can be of any format, and pass it to the next filter (MCF, OGG etc). This MCF-CD filter is similar to the current RIFF/CDXA one but with the MCF-CD features inside.

About the VCD/SVCD compatibility issue, well since a VCD/SVCD DAT file has basically the same structure than the ones produced with my tool, our RIFF/CDXA filter would take over (S)VCD files and won't let the MS MPEG-1 splitter open it (which has its own RIFF/CDXA parser). So I added an extended description at the Media Type registry key so it would only match files made with my tool. My M2F2 files have a "special" XA subheader which is not found in (S)VCDs, and reflects Form2/Data content. So yes, they can co-exist happily.

[DeXT]

I've done some more tweaks to avih's RIFF/CDXA filter. Now it's able to open a HUGE file without the need to previously read it entirely into memory. So the file is being read as it's needed. I'd suggest you to test it by reading any file directly off the CD. I think you'll see a BIG difference

Oh the filter not only works with MP3 but also MPEG-1 video (not VCDs made with Nero or the like, though; you must burn it with my tool). I know this has not much sense but this way you can test it with big mpeg files, since MP3s usually are very short.

Below is a direct link to the file, you'll have to deactivate any download manager.

webs.ono.com/de_xt/mcf/riffcdxa_filter_test3.zip

[oddball]

Will it work with OGM files?

[DeXT]

No, the Media Type recognition still isn't there. So you can only use formats which don't need a Media Type entry in the registry (such as MPEG-1 video & audio, and probably MPEG-2). OGG, AVI and others need this feature in order to work.

But as I said, this is a TEST filter so don't expect it to be usable in "real production". As I said standard XA Mode2Form2 has some flaws (file size, error protection) that needs to be addressed by an extended format (such as MCF-CD) in order to be really usable.

[oddball]

Just burned some test MP3 files and when I play them back they are all garlbed and jumpy. You can hear the music but it sounds like it's all chopped up with odd skipping sounds and Winamps time indicator keeps jumping backwards and forwards by a second or two.

Using the latest test3 filters but it does it with the older ones too. Using XP BTW. The thing is if I unregister the filters I can still play the files and they do the same thing. I am wondering if even though I have run regsvr32 /s asyncflt.ax (Made sure it was in the system32 folder to be sure and run the reg addition) it's correctly registered itself. May be a problem my end. I don't get any message to say the filters are registered or unregistered but cannot remember if I am supposed to or not.

[avih]

oddball:
to register the filter, run this from a directory that contain the asyncflt.ax file:

regsvr32 asyncflt.ax

you will get a message box saying if the filter is installed or not.

then double click on the .reg file to insert the info to the registry. (this part is so the file be automatically associated with the previously installed filter)

note that's only a direct show filter. it means that for now the file won't play on players that don't use the direct show filters chain.

i suggest trying windows media player 6.4 or 8, or zoom player. all these three should work with these files.

pls let us know whether you had success or not (yes, even if you have no more problems at all ), since it could be pointing at a bug with the current implementation.

regards
avi.

[Ughie]

Hi,

i tested the tool, i writed two mp3 files with the cd creator and mounted the imaged with daemon tools.

First mp3 was 320 kbps, second 128 kbps.

With WMP8 both files where verry choppy, then i used WMP 6.4. First file was still verry choppy, second was good. After that i rendered the mp3's with graphedit, same effect as WMP6.4

Ughie

[DeXT]

Well I should first ask the obvious: are you sure you installed the filter from this page, right? If you are not sure it was rightly installed follow avih's instructions (doing it through the command line).

I can't see any reason on why a 320 Kbps MP3 wouldn't work fine. I tried several MP3 files with WMP8, up to 256 Kbps, and all worked fine. BTW I have the Fraunhoffer MP3 CODEC installed. Try loading the original MP3 file into WMP8 to see if that's the cause.

Another thing you can try is manually loading the RIFF/CDXA Source filter into graphedit (i.e. the old way) because this choppy playback is mostly due to the filter not being loaded correctly.

If all this fails it would help that you point me to a link where I can download that MP3 file so I can test it by myself and eventually find a potential bug.

[oddball]

Same thing when manually registered. The filter says it is registered fine. If I unregister manually (To let it tell me that the filter is successfully unregistered) the filter unregisters correctly but I am still able to playback the files with the same errors. So the filter appears to be making little or no difference at all in being able to access the MCF burned files.

I am going to try an reboot and boot into Windows 2000 on the other partition to test. 1st without the filter and then with.

[Ughie]

I unregistred the filter manually => succes, after that i can't play the files anymore. error : the source filter for this file can't be loaded
So the filter did load correctly when it was registred

but there is something with that 380 kbps pm3 file.
Not written to MoreCD (or whaterver the name is) it plays fine in WMP8.0 and FreeAmp (Winamp not installed so i didn't try it) but it doesn't play well in WMP6.4 or rendered in graphedit When I write it to a MoreCD it doenst't play choppy like it was in WMP6.4 or graphedit but faster.

I have als tried it with graphedit, the old way, same problem

But don't bother with this file, it must be corrupt in some way or another, and is also time to reinstall my pc. I will test after a reïnstall (will take a day or 2, need to take many backups :-)

[Ughie]

i can play the 380 mp3 file from morecd now.
Problem was something with ac3 prologic filter.
When i render the mp3 file from the cd in graphedit it loads like this

.dat file => mpeg-I stream splitter => AC3 prologic decoder => Morgan stream splitter => default directsound device

like this it is choppy when i change it to this :

.dat file => mpeg-I stream-Splitter => default waveout device

it plays fine.

i can't use the directsound devicce without ac3 decoder. so it is one of this who has problems. (My audio card is a old Diamond monster mx300)

so the filter is correct it are driver problems or something

[avih]

thanx for taking the time to find the exact problem

we'll have to test if there's really a co-existance problem with other filters.

we'll check into it later.

thx
avi

[DeXT]

@ughie: Yes it seems that AC3 filter taking over MP3 files, instead of the good ol' Fraunhoffer, and perhaps related to the lack of proper Media Type recognition. I hope this will be solved when we add the Media Type code.

@oddball: well I think the source of your problems is that the Media Type key for RIFF/CDXA isn't working with your system. I think this because once the Media Type is installed, but the filter unregistered, you shouldn't be able to play the files, but an error message should appear ("source filter for this file cannot be loaded"), like in Ughie's case. Make sure that you double clic on the cdxa_media_type.reg file. If it doesn't work, perhaps this could be due to not having administrator rights in your system (check this), or a conflict with another existing filter that takes over RIFF/CDXA content.

[Peters]

Some report

I've burned a 'big' mp3 (320 kbps, 1h 20 mn, 200 Mo)
First i got a pb because of the Ligos Mpeg Parser Filter (no play at all)

After unregistering this filter, the mp3 plays fine with WMP 6.4
With WMP 8 it plays choppy ( original mp3 is fine)

[avih]

Just for making the tests easier:

here are individually compiled filters to support the following submedia types:

1. NULL (the same as previously released filter, somehow supports mp3)
2. MPEG1Audio (to support mp3 directly)
3. Avi (avi video files)
4. Ogg (ogg files)

only one of the above can be active at a time. 4 batch files are supplied to register each of the filters. (still no automatic media type detection).
there's no need to unregister before changing a filter.

small bugfix: these filters now support multiple instances.

-- WARNING WARNING WARNING --
this is alpha software. this means that if you start storing files using de_xt's tool now, THE BURNED FILES WILL NOT BE COMPATIBLE WITH FUTURE VERSIONS OF THIS STORAGE FORMAT. THE FORMAT IS NOT FINALIZED YET. (error correction hasn't been added yet)

although it's possible to use these filters to read 800M files directly from the cd and play them, you should NOT by any means start archiving your files using this format. these filters are only here for testing of playback, co-existance with other filters, smoothness of playback etc.

the reason you should not start archiving your clips using de_xt's tool is that there's no error correction. this means that if your cd is scratched, and important (=headers/indexes) parts of the file are lost, you will NOT be able to play your file.

de_xt's tool stores the files as standard m2f2 files on iso 9660 filesystem. this mode offers no error correction. what is lost is lost.

the final target is to modify the file BEFORE using de_xt tool, such that it contains error correction (=redundencies), and then use the tool to make an image of it. the filter would also be modified to use these redundencies when errors are detected.

atm though, THERE IS NO ERROR CORRECTION AND YOUR FILE MIGHT NEVER PLAY AGAIN IF THE CD HAS SCRATCHES WHERE IT MATTERS. be warned.

regards
avi.

feedback regarding usage of these filters is most welcome on this thread.
pls attach the following info:

- fileType(avi/ogg/etc)
- file size
- media (daemon tools/74Mins cd/80Mins cd/90/99/etc)
- playback: seeking/smoothness/etc
- anything else you think is important.

[edit]the attachment is zipped rar. i used rar since it compresses more than 300K to about 40K. it's wrapped by zip since the board doesn't allaw uploading of rar files.[/edit]