Request: Help with MCF-CD DShow filter

[avih]

@int21h
status is as follows:
1. we can make it to play any kind of media file, but we have to compile for each of them. we're now working on automatic media type detection so that the same compiled filter will work with all formats. the automatic recognition is based on ingo's work from mediaxw.

2. currently, it reads the whole file to memory. this will also be changed. and it's quite simple to correct this. in the meantime, don't use it with LARGE files or you'll run out of virtual memory ;)

3. we didn't yet tested how it works with actual scratched cd's. that's the purpose afterall, since there is no error correction. is still uses the sample code for reading the file. my assumption though is that it shuld be ok.

i guess few more days of working will fix #1 and #2. don't know about #3, since i don't know how much (if at all) effort it will take.

regards
avi.

ps.
can u play standard mcf files? i'm not aware of mcf tools atm :)

[robUx4]

No MCF tools for the moment (there is a very basic C implementation of a parser though on CVS). Otherwise the big library is under construction.

I hope the first beta/alpha will be ready for the end of May.

[avih]

and another thing.

after de_xt discussed it yesterday with tronic of the mcf team, we arrived at the conclusion that de_xt imaging tool, and the filter have nothing to do with mcf. meanning, it's standard iso 9660 file system, on standard mode 2 form 2 cd. just that. completely standard. we can call this format MCF-CD, 800CD, MoreCD or any other, but it may cause confusion, since it's NOT a new format. it's a standard inplementation of iso filesystem. theoretically, nero could support burning such images. i guess the only reason it doesn't is that it doesn't have error correction, and too many users will complain that their favourite xxx.exe file is not working anymore.

maybe "Project ISO: codename 800CD" in the meantime :) or just "800CD" to recognize the project (eventhough it can hold more or less, depending on the actual media, like in 99mins cd and 650M cds)


after reading the thread again, maybe MoreCD is more appropriate, most ppl seems to like it, and it doesn't have any specific relation. it's also more correct than 800CD..

it could also be named Full-CD or just FCD. at least it can be written as 3 letters abbrv. :) 3 letters is fast to write ;)

MCF-CD/MoreCD/800CD/FullCD ?

[oddball]

I wonder if there is a way to write to Form 2 Mode 2 on the fly for any data. Having to convert to a .bin file takes time and eats up hard disk space. Doesn't Nero have an option for plugins? Or maybe someone could write a simple Form 2 Mode 2 CD wrting prog. Doesn't have to do anything fancy. Just drag and drop files and burn.

But I am getting ahead of myself I guess ;)

[DeXT]

@oddball: yes there is a way, write your own CD mastering & burning application with M2F2 support :)

Now serious: if it would have existed any single tool or medium to write M2F2 files this way, I'd have never wrote this tool. But AFAIK currently this is the only way of doing it. Anyways BIN image creation is not a big pain, so until someone makes a better app you'll have to live with it.

I don't know of any single ISO mastering & burning tool which is open source. cdrecord and mkisofs are, but they are separate tools.

Now a further comment on avih words regarding MCF-CD, to make things clear: due to a lack of communication with MCF team I thought that my tool was MCF-CD, Ingo's version compatible (which is just a simple ISO Bridge, XA Form2 CD, as shown in the MCF-CD page). So I called it MCF-CD, althought I knew that at its current stage it's a 100% standard format. Until now I had this idea because no one told me this wasn't true.

Now after some talk in #mcf channel Tronic made me understand that Ingo's version notes are far from complete, regarding the "MCF-CD" format. The "true" MCF-CD is a mixture between Tronic's version and Ingo's one.

So the tool I've done as well as the DShow filter avih is developing has nothing to do with the "true" MCF-CD format, it's just a standard XA Form2 ISO Bridge CD (as I already knew). Now I'll start working in the "true" MCF-CD and make a tool which is fully compliant. In fact this is good because MCF-CD is a more secure format, solves some problems with standard M2F2 (such as the inaccurate file end), and could even make things easier to implement (such as the content media type retrieving).

I'd like to put this clear on my homepage but I cannot login to the ftp server (seems some ISP problem :(). I should also make clear that in its current state, this is just a test tool, which is not ready for the end user.

Oh I should note too that current Ingo's DS implementation isn't either MCF-CD compliant, because it loads from standard RIFF/CDXA file the same way our filter does (well at least this is what it seems to do because I haven't been able to make it work). I guess he was thinking in applyng some changes to it in future, to make it MCF-CD compliant, provided that this was his idea of MCF-CD of course.

(if I've missed something, any MCF team member should contact me ASAP)

[ChristianHJW]

Originally posted by DeXT (if I've missed something, any MCF team member should contact me ASAP)

No ! ;) .. we're glad to have you in the team De-xt !!

Only thing to add : CDR-DAO is a GPL burning soft, and can burn from Cue/Bin . It can be found on the TSCV homepage http://www.ttool.de AFAIK ....

EDIT : No, its here : http://sourceforge.net/projects/cdrdao/

[Koepi]

Hm, do I understand it right, it's going to be for MCF only?

I'm a little sad about this direction of development, but well, that's life, and that's exactly what Ingo writes about the "video coder community".

Anyways, good luck with it.

[avih]

koepi, come on. we have now MoreCD (at least that's leading the name poll), as a completely general solution for 800M storage on 80min cds. it's developing. no one is expected to start using this as of today.

just let both (MoreCD and mcf-cd) develop. i'm sure the community will prefere one over the other when they're both usable and more stable.

choice is good for consumer, as long as it's not turning into a war.

so far, there's no war, let's keep it this way :)

ppl are encouraged to try both when available, and decide which is better. u can't force a format, the one that will be more usable, will be more widespread. very simple.

best regards
avi

[oddball]

I don't care what it's called or what flavor it comes in. I just want my MPEG4 variant (And/Or MP3) on 800MB CD that's readable on the fly correctly, easy to create and does not suffer from data loss problems.

Whoever gets there first and whatever it is called makes no difference to me ;)

Side note: Anyone thought about contacting Ahead software who make Nero and asking for M2F2 as an extra advanced option for burning data?

Might be worth asking :)

[oddball]

Oh one more thing. Can we have the toption to keep files kept with their same filenames within the bin file? I realise that the software used was modified from a VCD imaging application. But I presume you have the source material to be able to modify it so that the filenames are not all .dat extensions and can retain their original naming convention? How hard would this be to implement? Would it break the way in which the data in written?

[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

[ChristianHJW]

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.

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.

[Demone]

So is it possible to burn an avi file that can be read with other version of the filter ?
I dont mind to make some movies with the filter without crc, but I'd still like to open them in the future :)

[Neo Neko]

You could do that. But a single error in the AVI would make it unreadable and the CD worthless. Anything could be written to the CD. But it is intended for formats with error recovery or redundancy. AVI is not in this category.

[Demone]

Where to get de_xt tool ?

[avih]

there will be no problem reading your files in the future.

the source code, and the filters are there.

it's simply stripping the riff header and the raw data from the file, as dext described on the 1st post of this thread. the file is read by windows normally, and it's a standard iso 9660 mode 2 form 2 filesystem.

but as neo neko said, if anything goes wrong with the cd, you won't have any error correction facilities to help.

that's why i don't recommend using it for actual archiving.

testing and feedback is ok though ;)

avi

[avih]

Originally posted by Demone
Where to get de_xt tool ?

http://webs.ono.com/usr016/de_xt/mcf.html

download mcfcdmaker
(don't mind the name. it creates perfectly standard iso9660 filestsyem image, and has nothing to do with mcf)

[chthonous]

I've tried to download the latest set of test filters (test4) a couple of times, but I keep getting crc errors when I try to unrar them. I've tried it with both winrar and winace. Is anyone else having this problem?

[MePrivat]

To avih

I tried your test4 build of the Dshow filter with a ogm file.
The ogm was a 600MB video with 2 audio layers each 95MB in size, which makes a total of 790MB burned onto an 80min CD-R. And.... it worked perfectly, scrolling back and forth, switching audio, pause, resume, etc...

To summarize: GREEEAT.

[Demone]

Probably its a stupid doubt, but as I'm going to try 90min cds, 'virtually' I should be able to burn a 900mb avi...

[avih]

Originally posted by MePrivat
To avih

I tried your test4 build of the Dshow filter with a ogm file.
The ogm was a 600MB video with 2 audio layers each 95MB in size, which makes a total of 790MB burned onto an 80min CD-R. And.... it worked perfectly, scrolling back and forth, switching audio, pause, resume, etc...

To summarize: GREEEAT.

fantastic :)

@Demone:
that SHOULD work, but untested. if u test this. let us know how it worked.

thx
avi

[Peters]

Originally posted by chthonous
I've tried to download the latest set of test filters (test4) a couple of times, but I keep getting crc errors when I try to unrar them. I've tried it with both winrar and winace. Is anyone else having this problem?

Updating your Winrar version (2.90 now) will solve this pb

[oddball]

Avih you say that there is no error correction. Isn't there any error correction in the OGM format? If you got a slight scratch on the CD-R would OGM still playback OK?

I have some Infinite 99 minute media. Once I am satisfied that this method works on a rewritable I will try it on one of those. Mmm. 999MB :)

BTW I found out some of the issues with playing back those MCF MP3's. I forgot that progs like Winamp don't rely on Windows DirectShow filters. Played back fine in Media Player 2.0 (Not tried 6.4 or 7 or 8 yet). I guess that is the drawback of using a DS filter. I would much rather the read back method relied on a generic M2F2 driver. Has anyone looked at the modified CDFS.VXD that was used for Win98? It apparently let folks read back any data as audio data (After being burned as a wav file). Not sure how relevant it is in this instance though

[avih]

@oddball:

the file is written as plain m2f2 file. that mode doesn't offer error correction (only error detection in the form of some crc).

it's true that ogg has good resilliance for errors, HOWEVER, since the stream is recognized by the filter itself (i.e. the Ogg dshow filter checks that the 1st 4 chars of an stream are 'Oggs' to identify it as an ogg stream), if we loose this info, we'll have no way to recreate it, since it's a mode2 form 2 file.

we're now thinking of the 'XCD' spec and define, among other things, the protection/backup scheme.

when we have a spec of the protection scheme, we'll write 'protectors' for each media type. ogg will probably be one the simplest, since very few info REALLY needs a back up (i.e. not much more than the 1st four chars, and maybe the first headers of the stream)

regards
avi

[avih]

Originally posted by oddball

BTW I found out some of the issues with playing back those MCF MP3's. I forgot that progs like Winamp don't rely on Windows DirectShow filters. Played back fine in Media Player 2.0 (Not tried 6.4 or 7 or 8 yet). I guess that is the drawback of using a DS filter. I would much rather the read back method relied on a generic M2F2 driver. Has anyone looked at the modified CDFS.VXD that was used for Win98? It apparently let folks read back any data as audio data (After being burned as a wav file). Not sure how relevant it is in this instance though

you are correct, it needs a parser for m2f2 files. i think a new filesystem driver is out of the question ('heavy' ;) ) , however, we do aim at writing plugins for XCD format for major media players that DON'T use direct show (i.e. winamp, mplayer, etc).

currently koepi and me are working on it. de_xt insists on defining himself as 'contributor' instead of 'developer' :), he helps us anyway, since we use his tool for making the images. he also is working on the dshow filter with me, and he's an invaluable source of info.

avi

[chthonous]

@ Peters

Thanks for the tip. It works fine now. I guess I didn't realize how outdated my version had gotten.:)

[ErMonnezZa]

I tried to burn a 800mb image with 'NERO' but it didnt work.
The problem seems the filter itself, cause using the dat2file prog on the .dat file from the burned cd, the generated avi file is ok.
The final effect is that the cd start spinning and reading forever, but the mediaplayer screen remains black.
Any help ?

[spyder]

I burned a 730Mb image on a 74-min CD with 2 mp3s(1 w/CRC 1 w/o) and one OGM which was 710Mb of it. On the resulting CD(and image in Daemon tools) the MP3s would play but they stuttered very badly and the OGM would freeze everything. How did you get it to work with the OGM?

I am using Win 98 SE with test4 of the filters.

[DeXT]

@ErMonnezZa: are you sure you've used the latest release? (test3 or test4). This behaviour remembers me the test2 version, because this one loaded the entire file into memory before trying to play it. Apart from that, I currently see no reason to explain this behaviour, but we'll try to reproduce the problem.

@spyder: the MP3 issue could be due to the MS File Source filter taking over RIFF/CDXA content. This is a known issue and we'll try to solve in future. The OGM issue, well i haven't tried it but perhaps it could be due to a slow M2F2 track reading, and the lack of buffering in the filter. I'd suggest you to copy the DAT file to the HD (with Explorer) and try to play it from here. I'd like to hear your report in this issue.

[ErMonnezZa]

no i am sure that i dowloaded the lastest version(test4).
are u sure that the avi filter included is the latest one?..
any other ideas ?

[spyder]

OGM is still a no go from my HD. I tried doing what you said in the first post on this forum(about writing a program to extract the file without RIFF headers). I wrote a program in Java(the only language I am very fluent in complex I/O ops) to remove the first 44 bytes(riff header) and then read 2324 bytes(user data) and skip the next 4 bytes(EDC). My program gives a resulting MP3 that sounds identical to the way it sounds when played from a CD using your filter(stutters badly).

Maybe you forgot to skip the 24 bytes(header) before the 2324 bytes of user data, like I did.

Also, my computer seems to try to load the whole 710Mb OGM before playing it. When I tried to play it from my HD, it just read and read.

[spyder]

Can you send me the source for the filter? Or is it closed at the moment? I would like to know how you go about abstracting the reading from the filter to read from the DAT file. I have been working on this for a while now and I have code(in Java, but similar to C++) that will convert a byte position in the virtual file(without headers, EDC, etc.) into the real position in the DAT file. it is as follows(I suppose C & C++ have the modulus(%) operator):

public int translatePosition(int pos){
if(pos < 0){
return 0;
}else{
int newPos = 0;
int sectorNumber = 0;
sectorNumber = pos / 2324; // number of stripped sectors before this sector
newPos = 44 + (sectorNumber * 2352) + 24 + (pos % 2324);//number of bytes in full sectors
//plus the header of this block and
//the bytes to be skipped in this sector
}
}

This method returns 0 if it is passed a position less than zero for safety reasons. Also note that in Java if you divide to integers you get only the integer value without the remainder.