Request: Help with MCF-CD DShow filter

[DeXT]

Hi again. I think most of you already know what's the MCF-CD project about, and the benefit this may bring for all the community. This post is focused at the Developers, specifically those with some DirectShow programming knowledge.

The MCF-CD is a reality. The only problem is, for it to be usable, a special DirectShow filter must be developed. This is needed because of the way Windows access M2F2 discs. It adds a RIFF/CDXA header to every file written this way and reads the file in RAW mode.

Althought this may sound complex, for anyone with minimal DS programming skills this is a very simple task. What we need is a File Source filter, or a Transform filter, that is able to bypass all this extra data and pass the useful data only to the next filter in the chain. This task is as simple as:

a) From the beggining of the file, discard the first 44 bytes (the RIFF header).
b) From here up to the end of the file, pass 2324 bytes of data out of every 2352 bytes in the file to the next filter. Each sector has the following structure:

struct sector {
char header[24];
char userdata[2324];
char edc[4];
}

What wee need is the userdata[] block only, the rest is discarded. This filter would only be used with movies because any other file would be written in Form1, which don't need any additional work.

As you can see, this is very simple. We (avih & me) have been playing with some sample DShow filters but seems we just don't have the skills to do such a thing. So any help on this matter would be greatly appreciated.

The main problems I currently have is:

¿How to implement a simple TransformFilter-based filter? (and NOT TransInPlaceFilter-based one as seen in the sample filters)

¿How do you know what amount of data is being requested from the next filter in the graph? So you can read the needed sectors from the file and pass the user data only.

Thanks in advance.

[Koepi]

I'm still a little reserved as it is called MCFCD.
I want to burn my OGG this way. So this format would be more or less EVCD (Enhanced [or Extended would suite as well] Video CD) instead of MCFCD.

Since not everybody is fixed and focused on MCF, you would get much more support if your focus wouldn't be just the one format that doesn't exist in "real world" yet.

Just my 2 cents,
Koepi

[DeXT]

Hi again Koepi. Well MCF-CD is just a name. This is how it is known by the community. But MCF-CD is not subject in any way to a single format such as MCF, specially since MCF doesn't exist yet. I think I should have put this more clear.

Eventually, if I develop MCF-specific features for this format, I will split the project in two parts: one MCF-only and the other totally generic. Probably this would lead to a name change.

But anyways if changing the name is a condition for you or anyone else giving help to this, I will do it. If you prefer it to be called OGG-CD when coupled with OGG content, I have no problem with it, too. In fact as you know this is the first format likely to be supported with these CDs is OGG, since it's the most suitable one at this time.

But please help to make OGG-CD a reality! (as you seem very devoted to OGG :))

P.S: I don't like much this "EVCD" thing. I should seek for a better one.

[avih]

i'm sure u're aware of it koepi, but maybe others aren't.

it's just the name that is 'specific' because it originated by mcf related developers.

however, this 'project' is completely general. the target is a dshow filter to parse files on the fly.
the files are stored as mode2 form 2 (this is already achieved, and we can burn 800M files to a cd). the only problem is that when openning the file in windows, we get extra information as de_xt described (the RIFF header is artificially generated by windows, the other extra data is raw data from the cd itself).

[Gawen]

Hope this is not redundant, otherwise smile about silly me.

Did you check the source of Multiple_MPEG2_Source.ax ?
(A file reader ax, in nimo codec pack for instance.) Its
officially source only on http://fysx.acwu.com/Code/Code.html
and downloadable from Dooms Source page.

LIBRARY Multiple_MPEG2_Source.ax
DESCRIPTION 'I-Media Multiple MPEG2 Source Filter'

It should be able to show you what you asked for, or?

[Koepi]

Hell, now you got me really wrong!

I just wanted to explain why there might be a lack of developer feedback.

As I wrote already, I'm stuck in some projects and can't afford the time to help in another one.

And: I'm not fixed on OGG. I just like it, it works, it is the best we have until now.

Until MCF becomes working reality it can take very long.

So don't misinterpret my lack of time with me not liking MCF.

Regards,
Koepi

[int 21h]

Originally posted by Gawen
Hope this is not redundant, otherwise smile about silly me.

Did you check the source of Multiple_MPEG2_Source.ax ?
(A file reader ax, in nimo codec pack for instance.) Its
officially source only on http://fysx.acwu.com/Code/Code.html
and downloadable from Dooms Source page.

LIBRARY Multiple_MPEG2_Source.ax
DESCRIPTION 'I-Media Multiple MPEG2 Source Filter'

It should be able to show you what you asked for, or?

Nah, this isn't what they need. They need something that does some file parsing. Similar to the Mpeg-1 Demultiplexxer for Windows.

[Neo Neko]

Nic has not put any visable time in on his AAC filter for a while and he has done such a good job on the Xvid filter maybey he might be a good person for this. I would jump on it in a heart beat if I could, but my programming knowledge tends to stear clear of OS specific issues. That and it is extreamly basic. ;)

[Gawen]

@INT 21H
Silly, silly me,

and i thought the problem was reading a file stream from a M2F2 ISO layer 2 formated CD track, parsing the leading 44 RIFF/CDXA header bytes to a fitting DS output pin definition on file open, buffering the input data after stripping block header and EDC and sending data from the buffer to a DS output pin on demand of (for instance) the OGG DS splitter.

But i am shure you are right, its impossible. Demuxing must shurely happen bevore the OGG splitter. And silly me tought this was the demuxer. I am so sorry. :-)

P.S.: There is another, imho even better DS file reader source example in avienc 0.20 available from http://www.geocities.com/ej_999/avienc_src020.zip

[ingoralfblum]

Originally posted by Koepi
I'm still a little reserved as it is called MCFCD.
I want to burn my OGG this way. So this format would be more or less EVCD (Enhanced [or Extended would suite as well] Video CD) instead of MCFCD.

Since not everybody is fixed and focused on MCF, you would get much more support if your focus wouldn't be just the one format that doesn't exist in "real world" yet.

I fully agree here. MCF-CD isn't a good choice for the name.

Regards,

Ingo

[ingoralfblum]

struct sector {
char header[24];
char userdata[2324];
char edc[4];
}

Sorry for my unsuitable comment here. I don't know much about DirectShow, but don't do these

RIFFCDXAReaderFilter.hpp (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/AVI/RIFFCDXAReaderFilter.hpp?rev=1.1&content-type=text/vnd.viewcvs-markup)
RIFFCDXAReaderFilter.cpp (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/AVI/RIFFCDXAReaderFilter.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup)

do exactly what you want. Perhaps they lack some functionality, but they should suffice at least for information purposes.

Kind regards,

Ingo

[Gawen]

I don't know much about DirectShow, but don't do these ... do exactly what you want.

And i thought understatement was British, not German, Mr. Free Codec Pack. :cool:

[oddball]

What is surprising me is the lack of takeup from any developers on making a DS filter for this format. Nobody appears to be leaping for the spec and trying to make one. I am sure everyone would love an extra 100 megs of available data on their 80 min CD-R's without sacrificing error protection (which should not be an issue with OGM etc). From what I have read it looks like it should be a simple enough task for anyone with DS filter programming knowledge. I may be wrong however as I cannot program to save my life (Well perhaps a little crappy basic) :)

Those last example files are from Ingo. Where can I find out more on what he is up to?

[robUx4]

Yeah, the MCF dev team welcomes any skilled developpers to help us.

I'm also a bit disappointed to see that, even though many people are interrested in both our current projects (MCF and MCF-CD) we get more attention, but nobody working on it.

Hopefully this is an initial situation since everything is in alpha state. So when it becomes beta much more people will have access to it and might be willing to add their knowledge on it :)

As for the MCF-CD name, I don't think it's a problem. As it was created by the MCF-CD team. Maybe MCD (something like VCD) could be used. But, in my opinion, MCF still deserves credit for that :) (and mostly Tronic and Ingo)

[DeXT]

@Gawen: thank you a lot for your help. I'm sure these sample filters will help us to understand a bit more how things works.

@Neko Neko: may God hear you... or is it Nic? ;)

@Ingo:
I fully agree here. MCF-CD isn't a good choice for the name.
surprisingly enough, since you are the "creator" of this format ;)

Anyways I think I should search a more-generic name, at least for the non-MCF related content. The problem is, it must be short and auto-explicative. CD/XA Bridge? Or just Mode2 CD? Or...
I don't know much about DirectShow
I assume you are just kidding here
but don't do these

RIFFCDXAReaderFilter.hpp
RIFFCDXAReaderFilter.cpp

do exactly what you want. Perhaps they lack some functionality, but they should suffice at least for information purposes.
Yes they should. The problem is, I can't understand a single line :) Seems this is part of a much larger project (with its own file reader and most DShow functions wrapped into your own ones -- at least this is how it appears to me). Anyways I wasn't able to make it work in its current form (sorry if I appear too dense; in fact I am :)). And since you said you were too busy to work on it I thought this was not suitable for us.

@oddball: Ingo's project is at http://mediaxw.sourceforge.net

[ingoralfblum]

Yes they should. The problem is, I can't understand a line :) Seems this is part of a much larger project (with its own file reader and most DShow functions wrapped into your own ones -- at least this is how it appears to me). Anyways I wasn't able to make it work in its current form (sorry if I appear too dense; in fact I am :)). And since you said you were too busy to work on it I thought this was not suitable for us.


Yes it replaces the MS DirectShow classes and the MFC. The only thing that is much different is the media type negotiation. Since Nic is quite experienced with DirectShow, this shouldn't be the problem for him. Ask him if he can take a look at it.

The next thing is, that it uses the class ingo::InputStream for file access. First for the underlying file and second to expose the content to the base class. But this is exactly the same as the mcf::IOCallback. The next missing is the class for the registry key, but you can either copy it to the MCF library, because it should work the fine without many modifications, or you use another class. But the basic thing is that you create a filter with the IAsyncreader interface on the output pin. The current implementation reads the underlying file directly. Instead you should have an input pin, that connects to another IAsyncReader. This is simple. There's already a wrapper class that exposes a InputStream interface for a given IAsyncReader. So that probably takes about 20 lines.

Tip: You should use http://sf.net/projects/mediaxw instead.

Regards,

Ingo

[Nic]

Ingo you're better than me at DShow :) I personally hate it, too much of a pain to debug :) but I always get asked to help with it.... :)

But this should be a relatively simple to do....Don't think I have the time right now though :(

I heard you'd given up a bit Ingo....I hope you'll be back coding with us soon/one day :)

Cheers,
-Nic

[Koepi]

sorry for the off-topic again,

but:

robux,

this isn't about someone deserving the credits or anything like that. I dislike this "protektoristische scheuklappen" attitude (don't know any translation for that).
MCF-CD simply is a very special name that should forbid any further usage.
So even the name should be more generic.
That's what I'm talking about. Some OGG developers could be attracted as well as other DShow "gurus" if it wasn't for "MCF only".

I hope now the point gets a little clearer.

And Ingo, I too hope that you won't give up your efforts, I know how bad this work can be sometimes, but in the end there is some new, usable programs/codecs/... which do move/change things for the future.

Best regards,
Koepi

[avih]

ok guys, 1st version of riff/cdxa is working.

sample usage:

0. register the filter asyncflt.ax (showed as 'Sample File Source (asynch)')
1. create a RIFF/CDXA cd image using de_xt's tool that is containing at least one mp3 file. (the tool is attached)
2. burn the image (or use deamon tools to mount it)
3. open graphedit, render a standard mp3 file from your HD.
4. insert the sample filter, select one of the AVSEQxx.DAT files from the cd (that was created from a mp3 file).
5. diconnect the original source file in the graph, and connect the output of the sample filter instead.
(you'll also have to reconnect the MPEG1 splitter output to the mp3 decoder).
6. press 'PLAY' :)

known issues: it won't work with avi or ogg files ... yet :), something to do with media types.
still have a lot of dshow stuff to learn. any help is welcome.

the only modified file from the sdk sample if asyncflt.h, which is attached.

the source and compiled filter + de_xt tool are attached. hope a moderator will approve it soon.

:)
avi

[Gawen]

@DeXT Was a pleasure for me, even if i am not a c coder, i know how to google. I like this project.

@robUx4 OT: I read on hydrogenaudio you offered help building an aac DS encoder. Any news?

@all
Naming: What do you think of MoreCD, files saved as *.mcd.iso?

Would sound neutral, reflect the benefit and would fit into your (the mcf dev team) name portfolio.

MoreCD.org is available:
Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

No match for domain "MORECD.ORG".

>>> Last update of whois database: Tue, 23 Apr 2002 04:59:53 EDT <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.

[avih]

ok.
managed to play AVSEQxx.DAT file that contain avi or ogg files :)

so i now know how to support (=playback on the fly using graphedit) mp3/avi/ogg files from a 800M cd burned using de_xt's tool.

still not automatically though.
i have to re-compile for every different media type i use :(

any help on automatic mediasubtype recognition (NOT by the file extention, since all the files are .DAT) is most welcome.

regards
avi.

[robUx4]

Originally posted by Koepi
sorry for the off-topic again,
robux,

this isn't about someone deserving the credits or anything like that. I dislike this "protektoristische scheuklappen" attitude (don't know any translation for that).
MCF-CD simply is a very special name that should forbid any further usage.
So even the name should be more generic.
That's what I'm talking about. Some OGG developers could be attracted as well as other DShow "gurus" if it wasn't for "MCF only".
Koepi

I know I know. The thing is that we'd like both format to be successfull and they well fit together. That was the idea when it was created... So the historical name IS MCF-CD, you can't change that. Now we could change the name to something else, why not. If there is much pressure from other people. But I also hope these same people could take some time to help these projects and not just asking more and more ;) That's why I consider that for the moment the format is highly related to MCF : it comes from there and is only there (for the moment).

I'm a bit exagerating, of course. But I wouldn't like another company endorsing MCF-CD as if it was their own. We are in the open (source) world, so things are a bit different than that, for the moment.

Some OSS projects don't give much credits to contributors, others does it clearly. I prefer those who give credits, even as an inspiration.

[robUx4]

Originally posted by avih
ok.
managed to play AVSEQxx.DAT file that contain avi or ogg files :)

so i now know how to support (=playback on the fly using graphedit) mp3/avi/ogg files from a 800M cd burned using de_xt's tool.

still not automatically though.
i have to re-compile for every different media type i use :(

any help on automatic mediasubtype recognition (NOT by the file extention, since all the files are .DAT) is most welcome.

regards
avi.

I'm not fully aware of the format, but before the "real" data there should be a header identifying what is in the file. Isn't that what the DirectShow parser would be for ? (I don't know the answer to this question)

[robUx4]

Originally posted by Gawen
@robUx4 OT: I read on hydrogenaudio you offered help building an aac DS encoder. Any news?

Well, it wasn't a DirectShow encoder, just an ACM (Audio Compression Manager), that's the old way in Windows to use audio codecs.

But right now I'm VERY busy on implementing libmcf, the library to parse and create MCF files. And that's my top priority. So the AAC/MPC/FLAC codec will come (hopefully) later.

Originally posted by Gawen
Naming: What do you think of MoreCD, files saved as *.mcd.iso?

MoreCD.org is available


That would be a good name :)

[Gawen]

@avih Seems the file type info is in the RIFF Header. I dont know what it means, but here you find M$ Riff header parsing:

Platform SDK: Windows Multimedia
MMCKINFO

The MMCKINFO structure contains information about a chunk in a RIFF file.

typedef struct {
FOURCC ckid;
DWORD cksize;
FOURCC fccType;
DWORD dwDataOffset;
DWORD dwFlags;
} MMCKINFO;


Members

ckid
Chunk identifier.cksize
Size, in bytes, of the data member of the chunk. The size of the data member does not include the 4-byte chunk identifier, the 4-byte chunk size, or the optional pad byte at the end of the data member.fccType
Form type for "RIFF" chunks or the list type for "LIST" chunks.dwDataOffset
File offset of the beginning of the chunk's data member, relative to the beginning of the file.dwFlags
Flags specifying additional information about the chunk. It can be zero or the following flag:

MMIO_DIRTY
The length of the chunk might have changed and should be updated by the mmioAscend function. This flag is set when a chunk is created by using the mmioCreateChunk function.
Requirements

Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Mmsystem.h; include Windows.h.
See Also

mmioAscend, mmioCreateChunk

http://msdn.microsoft.com/library/en-us/multimed/mmstr_57ci.asp?frame=true

The mmioOpen function opens a file for unbuffered or buffered I/O.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/mmfunc_665q.asp

@robUx4 I am happy you like it. :)

@Koepi Would MoreCD be neutral enough for OGG developers to support it? ;)

[Koepi]

Erm, you _want_ to get me wrong?

MoreCD sounds absolutely ok to me (but I guess we get trouble with Sony there? Didn't they call their propietary system MCD as well?)

I don't mean _me_ by any kind of mentioned developers. It's meant general.

But I'm glad that you're progressing very fast and well here!

Big thumbs up for creating a nice new format! :)

Best regards,
Koepi

[Gawen]

So maybe it should be called More;-)CD ?

Scratch *.mcd.iso, set *.morecd.iso

MoreCD has a meaning, its programmatic, mcd is just another 3 letter thing, so consumers will not mix that up. At least those i know. :D

@Koepi
Peace, brothers! All here do what they do for the community and fame. You are allready famous and theres enough space for gods of coding on mount olymp. I understand what you mean and i understand rob too. The name of a format usable for all should fit to their progs for their pride and still be usable for others without looking like thiefs. If i understand your sig well from a more emotional point of view: You know what pride is, so let them be proud. If they are, they will take good care of that baby and thats good for all.

[ingoralfblum]

any help on automatic mediasubtype recognition (NOT by the file extention, since all the files are .DAT) is most welcome.

If you look at the source that I pointed to already several times you see how this can be done. For the lazy here's the link:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/Base/ReaderFilter.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup

Try a look at the ReaderFilter::detectType() method.

I know, that my code lacks a good design, but is this single method really that difficult? Perhaps you should ask Steve (robux4), if he can help. He should be already familiar with my naming convention.
You probably want to read the part about how to register custom file types in the SDK first. There you see, that you can do it either by content or by extension and the method in the filter simply checks the content, based on the registry, first and if nothing matches it tries the extension.

Another question: Why do you name all files with the .dat extension?

Regards,

Ingo

[ingoralfblum]

All here do what they do for the community and fame.
Ahh, the buzzword comunity. I certainly do nothing for the community, whatever that community might be. When it's time for making profit the glorious community is gone faster than you can think.

Regards,

Ingo

[Gawen]

Originally posted by ingoralfblum

Ahh, the buzzword comunity. I certainly do nothing for the community, whatever that community might be. When it's time for making profit the glorious community is gone faster than you can think.

Ingo, imho there is nothing bad in earnig fame from a community of users of free software and there is also nothing bad in earnig money from customers. "You can not make a living from love alone, but if there was no love, nothing would live." (From an old stiched picture on my mothers kitchen wall) You say you certainly do nothing for whatever community. So what makes you visit this forum here in the middle of the night, pushing "lazy" people with their noses onto a solution they were asking for? And why does your work reside on a public server and not only on your local harddisk? In fact you do something for some users. When i try to support developers here i do in fact the same i do at work, where i ow money for it. Here i learn new things and i try to give something back. Scratch community, set exchange by free will.

[ingoralfblum]

You say you certainly do nothing for whatever community.

Yes, perhaps I do something for mankind, but not for a community, which is not there.

So what makes you visit this forum here in the middle of the night,

The fact that I went to bed at 17:00 yesterday.

pushing "lazy" people with their noses onto a solution they were asking for?

It is only a tip and be sure that they are not asking for what I posted. The source behind that link was already there 9 days ago and the people, that are now asking for it, already know that and already looked at it days ago.

And why does your work reside on a public server and not only on your local harddisk?
Yes, the old code resides there. Fortunately I canceled my SourceForge account and I'm happy with it. And the reason, that the code is still in a public CVS is the fact, that I have neither the time nor the resources to force OSDN to remove that code.

In fact you do something for some users.

Perhaps I try, but there's no effect. It's like running against a wall. Unfortunately it took years to recognize that - lost years.

Regards,

Ingo

[Neo Neko]

Ingo you give yourself to little credit. You may have been butting your head agianst a wall with this. But it was not anything the average joe could even begin to tackle. It was your project that really generated intrest in Vorbis for multimedia files in the first place. Everything that is today on this topic is partly because of you. So it was a near impossible task to get AVI to accept it. No one blames you. In fact we all understand even if in a limited way the dificulties you were facing. AVI ain't none to frindly to that type of data. It makes me sad when such good coders as yourself just throw in the towel like this. I hope that we have not seen the end of you even if you have discontinued your SF account.

You may not count yourself among the community. But be assured that there was one following your work. :)

[Gawen]

Originally posted by ingoralfblum
Perhaps I try, but there's no effect. It's like running against a wall. Unfortunately it took years to recognize that - lost years.[/B]

Ingo, if a job searches you, (and not you a job), you take it, you love it, you fight for it, you are the frontrunner ... then you will always be alone. Its in the nature of that kind of fight. It was your heart that kept you running on a road your intuition showed you. Thats why the job chose you. Next time simply give others a chance to follow and there will be a community around you. Or is there someting left you have to show yourself? If not come down from K2 take your seat on the fire and tell the others how it feels to be up there. ;)

(Been there, went back, was worth it)

[avih]

Originally posted by ingoralfblum

If you look at the source that I pointed to already several times you see how this can be done. For the lazy here's the link:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/Base/ReaderFilter.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup

Try a look at the ReaderFilter::detectType() method.

I know, that my code lacks a good design, but is this single method really that difficult? Perhaps you should ask Steve (robux4), if he can help. He should be already familiar with my naming convention.
You probably want to read the part about how to register custom file types in the SDK first. There you see, that you can do it either by content or by extension and the method in the filter simply checks the content, based on the registry, first and if nothing matches it tries the extension.

Another question: Why do you name all files with the .dat extension?

Regards,

Ingo

ingo, you are right. i didn't look at the code, although i could have, few days ago, as you noted.

i guess i should take the blame on me for beeing 'lazy'. and yes, i did start reading the sdk about registration and association yesterday, before i saw your post. i downloaded a hex editor and checked the content of different media files (to find that .avi i.e. is a riff file that can be recognized by it's riff type). so now i know we have riff (avi file) inside a riff (cdxa file). i was just excited that it worked, that i wanted further info to improve it. i started to look at the documentation as soon as i posted my question. either i will find the answer, or someone with more experience help me. thanx for your links.

regarding the files with .dat extention. well, i didn't make the imaging application (i think de_xt modified it from vcdimager or something), so it's based on s/vcd imaging applications, and it generates all the files as .DAT. i did a quick search through the code and couldn't find 'AVSEQ', so i figured the name is automatically generated by windoes when it mounts a m2f2 cd. i was just called for help with specific problem (non-existant dshow parser for this format) and that's what i started to work on. i didn't go to it's roots, bacause it seemed working and because i don't have too much knoledge of cd formats.

regarding open_source/audio/video 'community', well, u can't ignore the fact that one exists. for open source, well, i guess some do it for the fame, but some do it as a personal challange. no doubt some do it for both. i wouldn't mind getting some fame on the way, but it's not the purpose of my programming. i like the CHALANGE and i like the usable result and it's just FUN for me. i think many would agree with that way of thinking.

i came to this forum just couple of months ago, because i needed help. now i sometimes help others. before some months ago i've never done any video coding/postprocessing/editing/anything else, not as a user and not as a programmer. now i know what colorspaces are, what interlacing is and what dshow is and much more. i could have learned it all from reading manuals and web pages, but u just can't compare it to human feedback. that's the community.

i do hope you'll stay around, and code for your pleasure, and that others will be able to enjoy your work.

best regards
avi.

[DeXT]

Well tonight I was playing with the code avih posted here and now I've up and running the auto association with RIFF/CDXA content. What this means is, now you don't need to manually load the filter in GraphEdit but a simple double clic on the DAT file will load this filter. So this makes things much easier to test now.

I've also changed some things that needed to be done: create a new GUID for it, change its Friendly Name (now it's called "RIFF/CDXA Source"), tweak the Load() function to work with the new Media Type.

Below is the modified code. I've added two BAT files to (un)register it easily.

I had to do a small "hack" with the RIFF media type because, as I suspected, it broke VCD/SVCD compatibility (men you never listen to me). So this currently works only with CDs made with mcfcdmaker (anyways this isn't a big problem, isn't it? ;)).

About the problem Avih talked about (the Media Subtype passing to the next filter) I think we'll have it solved soon. Thanks Ingo for the tips. I already knowed how to create a custom type, I was only hoping that Windows were smart enough to re-create the Media Type out of the output stream. I now see this must be done manually by us, the same way you did in the detectType() method.

BTW, the DAT extension, I simply chose not to change it, because a DAT file is commonly a RIFF/CDXA one, and many people already has associated it with their Player. For the MCF content (and/or OGG) perhaps I should change it for a more suitable one. But this is part of the future MCF-CD specs, which I'd like someone start discussing with me ASAP.

PS: Ingo, I'm sad you are leaving, I only hope you really don't think all these years' work is lost lime.

[BTW i hope a moderator will approve this attachment soon]

[avih]

>"About the problem Avih talked about (the Media Subtype passing to the next filter) I think we'll have it solved soon. Thanks Ingo for the tips. I already know how to create a custom type, I was only hoping that Windows were smart enough to re-create the Media Type out of the output stream. I now see this must be done manually by us, the same way you did in the detectType() method."

i've found out that windows can render the chain automatically if it has a compatible mediasubtype. i.e. when it was compiled with mediasubtype_ogg, loading the filter with ogg-riff-cdxa file, and clicking 'render pin' will render a functional ogg chain that will playback ok.

nice work dext. these are indeed exciting times :)

[tg0021]

@ DeXT : tryed your DS-filter with a 15 MP3 files MCFCD. We tryed then to open the file with WMP6.4. It works for the first file (AVSEQ01.dat) but the others sounds jerky. Sometimes WMP craches with the first file after trying another one. Anyway, your work is really impressive... :cool: Keep going : I'm a fan ! :D :D

[ChristianHJW]

Originally posted by avih
regarding open_source/audio/video 'community', well, u can't ignore the fact that one exists. for open source, well, i guess some do it for the fame, but some do it as a personal challange. no doubt some do it for both. i wouldn't mind getting some fame on the way, but it's not the purpose of my programming. i like the CHALANGE and i like the usable result and it's just FUN for me. i think many would agree with that way of thinking.

Originally posted by de_xt
PS: Ingo, I'm sad you are leaving, I only hope you really don't think all these years' work is lost lime.

Guys, i dont think ingo is talking about the same thing as you do. In Germany the word 'community' does not only mean a bunch people living in the same village or interested in the same topic, but from the historical understanding of the word it means people helping and respecting each other.

After having had several conversations with ingo about this subject i do have the impression he is very disappointed about the way things were working out for his ambitious MediaXW project and the way cooperation is generally working in the video/audio encoding scene.
He had been investing a lot of time into his libraries ( forgive me if i post rubbish, i'm no coder ) to replace the Windows libraries to allow compilation of the MediaXW sources on different platforms. Tobias had released his Vorbis DirectShowFilters same time ( of course its much easier if you can use the Windows DirectShow SDK i guess ) and the whole community started using them as we all ( including me ) here and on powerdivx.com pushed it a lot as the long expected alternative to AVI. Ingo mentioned to me one day he was a bit disappointed why Tobias had not tried to approach him for cooperation, as he knew well about the existence of the MediaXW project. Well, i asked Tobias this question one day and he said he didnt believe AVI was a good container for Vorbis ( being true ) ..... but of course ingo was aware of this also, so they for sure could have started a cooperation with mutual benefit instead of both being 'the lonesome cowboy fighting for justice..' .

So, now, and this is not the 2nd but the 3rd or 4th time this happens to him, people again start to reinvent the wheel instead of looking at his sources where he has been investing so much precious time .... can you understand his reaction now ??

Whats under the bottomline ? Again its all about communication ... misunderstandings and misinterpretations everywhere ! Thats why i am still convinced people like myself, being no coders, can contribute to a project like MCF or Ogg by doing nothing else than keeping up a good communication about it, making sure relevant informations are digged out and passed to the right people.

And folks ..... its not too late ;) !! You wonna motivate ingo to keep up the incredible work he did ? Well .... start using his sources and give him feedback !!

[robUx4]

The sadest part is that you can't even blame Ingo for not giving more documentation on his work, because he has collected an impressive collection of documentation on the subject he was working on. And it was published on the web (I think it still is).

Now maybe the sources are a bit hard to get into. I know because he uses all the great possibilities of C++ so you have to know and understand them to really be able to read the code.

Anyway, this is not a topic about Ingo ;)

[BlackSun]

Agreed. Ingo is an incredible coder and he has done a lot. His project is certainly as big as VirtualDub and I really like what he has done.

He has done a lot for the community, it's sure, and we still need him !!

Ingo, I am your 1st supporter and can appreciate what you have done/you are doing...

[robUx4]

Originally posted by BlackSun
Coming Soon... The Concentric Circles of Audio and Video
http://www.corecodec.com

Which circle is inside the other ? :devil:
:D

[BlackSun]

Stop bugging me :D

Edit: this section has not yet been uploaded/updated
mouhaha :) lol

[DeXT]

@Chris: yes I also think the way the "multimedia" scene works is far from perfect. But I think we cannot be blamed of "reinventing the wheel" with this filter. I've TRIED to get help from anyone, but no one had time to do the work, or give some help. And it should be noted that I started working on this only after Ingo leaved, and after realising no one would continue the work on his filter.

In fact I also tried to reuse his code but as I said, this is too difficult for me. I didn't even know where to start. So the only thing I could do is write a new filter based on a sample code. At least I have a clear idea on how to do it this way.

So yes, we've also suffered from lack of help from the "community". We (avih & me) are not DS experts, and still have several problems. But we have resigned this is the only way of making things go ahead. Anyways I still hope that a good C++ programmer will take Ingo's work and continue it.

[DeXT]

@tg0021: Oh I almost forgot, thank you A LOT for your report, it was a stupid mistake from me with the last minute VCD/SVCD compatibility hack. Our filter was not being used with tracks 2 and up, but MS one instead (this causes the jerky playback).

Below you have the fixed file (once it's approved). In fact it only needs a change in the *.reg file.

Thank you for your support.

[tg0021]

Originally posted by DeXT
@tg0021: Oh I almost forgot, thank you A LOT for your report, it was a stupid mistake from me with the last minute VCD/SVCD compatibility hack. Our filter was not being used with tracks 2 and up, but MS one instead (this causes the jerky playback).

Below you have the fixed file. In fact it only needs a change in the *.reg file.

Thank you for your support.
Thanks for this quick fix. We'll keep on testing your filter : it's a great job :)

[avih]

dext, i can't see the fix.
can u pls send it to me by email?
avihpit
at
yahoo
dot
com

thx

[Peters]

avih,DeXT, your filter works great.

Radlight works fine with it (No success with Bsplayer)

Thank's for all (and to all)

[avih]

it's also working with zoomplayer and wmp8 (didn't check wmp6.4). i wonder about bsplayer though... i just tried and it didn't play. it complains about unknown file format, which is correct, it's a raw data file and not an mp3 file, that's what the filter is for, to strip the raw data, and leave us with the original file.

i guess bsplayer doesn't use dshow graphs normally, but some kind of internal code...

good point though.

avi.

[int 21h]

So what is the status of the filter? It's working with any files? OGM, MCF, MP4, etc?

[Peters]

Opening a movie (without sound) with Bsplayer and then opening audio file (.dat in this case) works.

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

[Sygma21]

I burned 790MB OGG/Xvid file with one 192Kbps vorbis soundtrack and chapters. Works fine ! Good seeking and chapter support with WMP 6.4 and Zoomplayer ;)

Really great

Regards

[spyder]

Why do you have to have a different compile of the filter for each file type? I figured the next filter would just call back to the source filter for so many bytes from a certain position in the file. if that were the case, it shouldn't matter what type of file it was if the next filter would determine type like when you use the File Source filter. I know the source filter doesn't have to have the type hard coded into it or we would not be able to use the Ogg DS filters. From what I see in the Async Filter source, it does just what I said, calls back for data. In that case it should be easy to code once you can translate the positions correctly and be able to read over multiple sectors. I am not trying to make anyone look stupid. If this is not the case please tell me. I am just trying to help because I would really love to be able to put 800MB on a CD. I have little experience in C++ but I know basicly how DirectShow filters work. I have no experience in DShow programming though.

[avih]

@spider:
the source to the filter is attached to the download.

you may have a look at it. attached are only the modified files (asyncflt.h and asyncflt.cpp) from the sample 'file source filter' from the directx8.1 sdk (samples\multimedia\dshow\filters\async)

Why do you have to have a different compile of the filter for each file type?

this is an annoying question. please find 10 mins to spare, and read all of the posts on this thread. you will get your answer. u can also read the readme.txt and warning.txt files that are attached to the download.

regarding the skippy playback from your HD: since many ppl found it to work well so far, it's not very probable that it doesn't parse the file correctly only for you. therefore i suggest doing a manual test (this is for an ogg file, for mp3 file mofidy step 1 accordingly):

1. double click the register_ogg_media.bat file. make sure you get a message box that the filter was registered ok.
2. open graphedit -> insert filter -> dshow filters-> RIFF/CDXA source-> select your dat file that was created from an ogg file.
3.right click on the output pin and select 'render'
4. press 'play' let us know if it plays ok now.

[spyder]

No matter what I do it will say it cant render the pin and it won't connect to the Ogg splitter. I unregistered all of the different compiles to make sure they werent conflicting and then re-registered the Ogg file one. No change. The MP3 works fine now though, must have been Microsoft crap screwing it up.

[avih]

spyder:

- do u have the latest ogg dshow installed? (0.9.9.1 i think).
- what kind of ogg stream are you trying (audio or a/v)?
- did u have any success with 'avi' files?
- does the original file playes from your hd with wmp? (the ogg file, NOT the dat)

[AlwSN5]

I burned a 799 mb ogm file (1 XviD stream, 1 Ogg audio stream) and it reads off the cd perfectly. It actually reads smother than most cds I burn in mode 1. Just wanted to give you another report of success.

Regards,
Alw Seldon

[ReferenceDivx]

I also just burned a 790 MB (Xvid, Ogg) file to a cd. It worked awsome. It seeked perfectly and played back great. I didnt see any errors, but maybe after a few years the cdr will go bad. But for now this technology is looking great.

Keep up the good work guys!

P.S. I've been working on a secret video coding project for the last couple weeks. Hopefully eventually I'll be able to release it.

[TheXung]

Are you guys sure ogm is that immune to errors in the stream? I tried truncating an ogm file on my hard drive and while it still played, it pretty much lost seeking ability.

[Demone]

Success here too.
I burned a perfectly 800mb avi file (after de_xt tool, nero reported it to be 812mb) and I'm moving to a 90 minutes cdr just to see if I can reach 900mb.
I noticed some slow down, but I think its only a media problem.

[avih]

Originally posted by TheXung
Are you guys sure ogm is that immune to errors in the stream? I tried truncating an ogm file on my hard drive and while it still played, it pretty much lost seeking ability.

we still don't know exactly how much ogg is immuned to errors.

we will talk to tobias, and ask him for the preffered protection scheme for ogg files.

do remember, there's NO error correction yet. when we have error correction implemented, we'll start looking for best protection scheme for each media type.


@spyder and everyone else without success:
if u still don't succed in using this stuff, can u pls describe the WHOLE process in much details. don't say 'the file' for example, but 'aviseq00.dat' etc. the WHOLE precess pls. and do make sure the original file plays ok before you start using this 800M stuff. and also, try with daemon tools before u actually burn. it it won't play with daemon, it won't play from the burned cd.
if you were experiencing problems, but managed to solve them, pls share this info, such that others can benifit from it.

@all ppl reporting:
thx. that's very nice to hear it's working for many :), keep them comming (yes, even the bad ones), and also report your OS, i think it could also be a source of problem, but i don't know yet.

avi

[Demone]

My current OS is Win2k, I'm going to test it with XP too.
BTW how to mount the file without burn it ?
thx

[Ughie]

you can mount the file without burning it with daemon tools. http://www.daemon-tools.com

all the test that i have done are with windows XP. Works good

[DeXT]

@ErMonnezZa & spyder: I think this "seeking forever" problem, as well as the unrecognized file and/or choppy MP3 playback, are due to a conflict between our RIFF/CDXA reader filter and another existing CDXA filter (usually third-party MPEG-2 filters such as Elecard, or the MS "VCD source" -- in fact the MPEG splitter). When one of these filters load the DAT file, it will start seeking the entire file looking for MPEG content. To avoid this try to uninstall such filters .The M$ one can be deactivated with the following registry patch (it can be restored, too):

http://webs.ono.com/de_xt/vcd_source_patch.zip

So I'd suggest you to try this patch and report any change. This does not mean you won't be able to watch VCD content, though.

@spyder: well about your troubles with OGG, are you completely sure the file is being burned properly? Some burners seems having trouble with Mode2 content. So first you should try this: convert the file back to its oroginal form with my dat2file and try to play it, if it doesn't works this means your burner probably has meessed up the file contents when burning. In this case I'd suggest you to try to burn as a single track with Nero: File/Burn image, load *.BIN (not CUE!), select Mode2 and burn.

However if it works fine then you know the file is right and the problem is in the DS filter. As I said I think it's due to a filter conflict so try the procedure above mentioned.

@RefDivx: I'd LOVE seeing your work ;)

@spyder (again): the recompiled versions are just a dirty hack to allow you to use any content different than MP3/MPEG, because of the lack of Media Type detection code in the filter (yet). BTW thanks for the code, but I think the avih one is implemented the same way.

@all of you reporting: thank you very much, without your notes we couldn't fix potential problems and of course seeing when we are taking the right path!

[DeXT]

BTW the Media Type detection is out, now you can use any file format without having to switch between different compiles. Avih published it in this thread:

http://forum.doom9.org/showthread.php?s=&threadid=24288

Now the only thing left is buffering I guess.

[spyder]

I don't have time to thoroughly test the new filters yet though I have tried them once and still a no go with any type. I think it has something to do with the incompatibility of filters. I tried the registry hack some one posted but it says its not a valid registry script. I am using windows 98 SE (ancient I know but cant afford XP yet). I did test the older filters with grapedit and it worked with MP3 but not OGG. I will try the new ones later or maybe tomorrow. I feel very ignorant for posting the code when it is almost identical to avih's version. I am just not use to the separation of code in c++. I didn't think to look in the header file. All of the code I had been working on is right there(but in c++). You guys are doing a great job. I will try the new filters out and will explain in detail what happens. Don't worry about the CDs, I am using a CD-RW(fully erasing). My burner has no problem with mode 2 but I tried Daemon tools and it didn't work so I thought maybe burning it would work an maybe Daemon tools had something off in it. I am glad that you have the media detection type figured out. That's great. I will let you know how the tests go. Meanwhile maybe someone could post a Registry fix for every version of Windows (If they already haven't).

[spyder]

OK, after plunging into the registry and deleting all keys with the GUIDs listed in the regfix(since it wouldn't work on 98se apparently) and re-registering the new filter(updated the REG again), I have gotten all files I tried to work(from Daemon tools and CD-RW). One is an OGM(XviD with Vorbis) and two were MP3(one w/CRC one w/o). All worked fine. AVI also works(DivX 5 w/MP3).

The only other thing besides Error checking that I think should be implemented is some way of determining how long the file originally was so that the trailing zeroes can be chopped. This might be able to allow ID3 tags to work on the MP3s again. They will not work with the extra zeroes because they are normally the last 128 bytes and start with 3 bytes("TAG", v1 & v1.1 anyway). ID3 v2 I think is different because it uses frames within the file I think. Maybe we could add a sector to the beginning of each track to include this and any other information about the track(maybe a CRC of the original file perhaps to verify extraction). A lot could be stored in 2324 bytes. it should only require that you tell it how many bytes were filled at the end of the track so we would only need 16-bits at most because of the sector size.

[ph2t]

Guys,

just a quick one, I've noticed every CD I've burnt now comes up the the volume label MCF-CD. Is there a way yet to be able to change the CD volume label? I take it that it is stored in the .BIN file.

Regards,

Ph2t.

[DeXT]

@spyder: I'm glad you finally solved it. Yes it seems it was a filter conflict as I suspected. Sorry it was my fault with the registry patch files, they were in Unicode format and Win98 doesn't support that. It's fixed now.

About the file length issue, I talked about it some time ago, this is one of the main limitations of "generic" M2F2 format, so the only way of fixing this is to use an "extended" format such as MCF-CD or XCD. This is why I wouldn't recommend using this for "real work". Anyways I think ID3v2 should work fine since it's located at the start of the file.

@ph2t: yes I forgot to remove this, sorry. I will fix this in the next release along with some new command line options to put your own volume label, etc. Meanwhile you can change it from the BIN image itself with a good hex editor such as HEdit.

[spectra]

i first had some problems with the reg entries as they were pointing to a wrong filter and as a result my media player was seeking the cd infinitely.

now after reading some posts and cut-and-pasting some posted regfiles - i ended up with playing a 775MB DivX5-VBR MP3 avi file directly from cdrw without problems.

my final w98 filter-regfile locks like this, i don't know if this could help anybody but with my system it worked.
(i take no responsibility for screwing up your system)

REGEDIT4

[HKEY_CLASSES_ROOT\Media Type\{e436eb83-524f-11ce-9f53-0020af0ba770}\{E436EB85-524F-11CE-9F53-0020AF0BA770}]
"0" = "0,4,,52494646,8,4,,43445841,60,8,00FFFFFF00FFFFFF,0100680001006800"
"Source Filter" = "{950AD390-D2DA-4029-BFD6-ECF019D3EF56}"

[ErMonnezZa]

OK: using the reg Key given by Dext(tnx :) ) and putting manually(since my s.o. is w98 S.E.) now i can finally watch the video stream but i have some problems:

1) i can only open the movie with bs player, (if i try using mediaplayer2 it goes to the eternal loop,finally giving vxd error and strange blu screens of death)

2)i can't hear the ac3 audio, if i go to the bsplayer preferences the audio is detected like ivi..so it is recognized but it doesn't work. maybe could be a problem of incompatibility of the creative suondblaster liveplayer 5.1 that suck with her incompatibility with ac3(but with bsplayer always worked on my system!)

3)i burned that avi file in a 800 mb cd with a final result of 881 mb..but it could be only loaded from the mastercd..and with some problems for reading..sometimes going to the loop...with dvd-rom(pioneer) is impossible to read anything and i can hear aggressive knocks to the cd ...are the 800 mb cd that suck and are still not compatible?

[ErMonnezZa]

i solved the 2nd problem...is Creative that sucks...now i can hear the audio too :)

[MaTTeR]

Originally posted by ErMonnezZa
Creative that sucks...now i can hear the audio too :)

Indeed they do:devil:

[MaTTeR]

I have to say I'm very impressed guys;) I just burnt a 772MB OGM file with Vorbis and XviD. The plackback is super smooth and seeking works perfectly with PowerDivx4, BSPlayer and ZoomPlayer.

Many thanks to everyone who contributed to the success. Next test for me is going to be 816MB overburned to Imation Silver media:D

[DeXT]

@ErMonnezZa:

1) well I definitely think you have some kind of filter conflict. This seeking forever is probably caused by another filter in your system trying to take over the DAT file and searching for MPEG-2 inside. Can you save the following registry key with all the subkeys and send it to me?

[HKEY_CLASSES_ROOT\Media Type]

You can also try spectra patch to see if it makes any difference. What it does is fix the MS VCD entry to point at my filter instead of the default file reader.

3) thanks for the report. I think the problem may be with the sector headers since I dont have any specs regarding the 90 min. CD format. The standard sector headers only allows up to 84 minutes or so. A fix could be possible, though: I could add an option to output a MODE2/2336 BIN image which doesn't include the sector headers so these would be generated by the burner itself.

@MaTTer: nice ;)

[spyder]

I would like to try working on this filter a little to try and fix the zero padding problems. But I don't have the DirectShow SDK. Does anyone know how I could get it for cheap without having to download it(I am on regular 56k).

[avih]

Originally posted by spyder
I would like to try working on this filter a little to try and fix the zero padding problems. But I don't have the DirectShow SDK. Does anyone know how I could get it for cheap without having to download it(I am on regular 56k).

the filter doesn't have a problem with the padded '0'. it's a limitation of mode 2 form 2 standard. file size must be multiple of user data block on the sector.

regarding a 'minimal sdk', well, i think it's possible to try and find a minimal set, but that would take long time to do, and it would be illegal to distrib the sdk partially.

i think it will be faster if u let your modem work on it for the night (or maybe 2 nights).

avi

[Demone]

Regarding the non correction codes implemented in XCD???, if I use ogg that have crc itself could solve the problem, or u still need crc on the media ?

[avih]

to make this issue once and for all clear!!!:

first, some annotations:

EDC: Error Detection Code (CRC)- this allow to recognize an error, but not to recover from it. the current tool support EDC only.

ECC: Error Correction Code - this allows recovery of (partially) damaged data, by including some 'smart' redundancies in the sector. ECC is implemented in 'standard' cd rom files. so if we have minor scratches, they are recoverable (but it won't work if you punch a whole in the cd though ). ECC is about 13% of the cd space. so 80Mins cd have about 800M space, out of which ~700M are actual data, and ~100M are ECC. the ECC is sector based, as defined in CD-ROM spec.

so why do we need ECC, on top of what is offered by the containers??:

1. because not ALL formats support inherent error correction/detection. since we aim this spec to be a general multimedia cd, multimedia 'objects' such as giff, jpg, or even a power point presentation don't have any error resilliance at all. so such formats must be 'protected' somehow. that's why we should define a protection method, and then apply different schemes of this method for different multimedia files. (i.e. gif file will be fully protected (= the whole file with ECC), while ogg file will be minimally protected (= only small part of it will have ECC))

2. even containers that have internal ECC, or can live with EDC only, and can keep the file playing even if it has errors, will not play if the player can't recognize the file type. usually the player recognizes the file type by reading the a few characters from the begining of the file. ogg i.e. searches for 'OggS' as the 1st 4 characters of the file. so if that data is lost the file may indeed be playable, the the player (or the ogg dshow filter for example) won't be able to recognize it as an ogg stream, and the file won't play.

3. storing files as mode 2 form 2 has some limitation, on top of the fact that this mode offers EDC only: the file can't have 'exact' size. we can only know how many sector it's spread on. so dext's tool pads the file with trailing '0'. but there's no way to know the actual original size of the file. so that info has to be stored somewhere.

4. since we want this format to be compatible with as many players/OSs as possible, we decided to stick to filenames in the 8.3 convention (like s/vcd), so we can't hold the original file name anyway, and we should store it somewhere.

and the conclusion is to include a special file we call a 'header' that will have the original file name, it's original size, possibly content tags (maybe ID3) and actual backups for 'sensitive' parts of the original media file. this file will be a mode 2 form 1 file, which offers ECC. so it'll be as 'protected' as normal files are stored on cd's nowdays.

and that's what this 'protection' is all about

currently dext's tool and the filter support only a single standard mode 2 form 2 file with EDC only.

we're now working on the spec to allow the 'protection'

simple?? :)

avi

[Demone]

Very simple and understanding, but I dreamed of 800mb on a 700mb cd :)
The problem is da space, if ogg is a more secure container than avi do u recommend to burn an ogg in a form2 CD at this point ?

[avih]

AT THIS POINT I DON'T RECOMMEND STORING ANYTHING FOR REAL ARCHIVING.

i think i've published enough info to make the issue clear. if you still don't understand then you may either take our recommendation, or read all the posts again, and make a better effort to understand.
however, since i don't own you or your clips or your CD's you may do anything you like.

JUST DON'T YOU EVER COMPLAIN THAT YOUR RARE BIRTHDAY CLIP STOPPED WORKING AFTER SOME TIME.

when we think it's safe enough to store your clips using m2f2, we'll make an announcement.

i consider that end of discussion on this issue, and i won't answer any more questions like "yes, i understand, but can i now store <abc> format since it's <xyz>?"

avi

[Demone]

Sorry I didnt want to hurt u, its that when u said u can put 800mb on a cd I think everyone were super-happy, but now ur saing that u'r going to add ecc again so I thought wtf no more 800mb then.
If u think that for example in an ogg file ur going to sacrifice the 0,5% of the space for ecc then I think I can live with it :p

Sorry again for my questions

[avih]

Originally posted by Demone
Sorry I didnt want to hurt u, its that when u said u can put 800mb on a cd I think everyone were super-happy, but now ur saing that u'r going to add ecc again so I thought wtf no more 800mb then.
If u think that for example in an ogg file ur going to sacrifice the 0,5% of the space for ecc then I think I can live with it :p

Sorry again for my questions

you don't have to be sorry, and you didn't hurt me, you'll find that hard to do, but u DID annoy me. if you read section 2 of the 'clarification' post (as u probably did now, as u seem to understand it) you wouldn't have to ask about it again (and you're not the 1st) and could either answer it by yourself or take the recommendation as is if u absolutely couldn't understand this.

the work done so far is considered by us as a proof of concept (or a demo). nothing more. and there's a long way between a demo and a 'product' (even if the demo seems functional at 1st glance). we published the limitations dozens of times now. this demo is not supported by us, except for testing and bug reports. that's it.

no harm done though. but next time just read carefully before you ask questions that were answered 2 posts before, and numerous times previously on the very same thread.

regards
avi

[robUx4]

Originally posted by Demone
Very simple and understanding, but I dreamed of 800mb on a 700mb cd :)
The problem is da space, if ogg is a more secure container than avi do u recommend to burn an ogg in a form2 CD at this point ?

OGG has Error Detection not Error Correction. So you might lose data (but the file will still play normally with some data missing, AVI would not).

[MaTTeR]

Ouch, this thread is almost ready to split:)

Just wanted to post some of the testing I've done over the past 4hrs or so:confused: I've successfully created several large Ogg file with Vorbis audio and burnt them. The playback on the Lite-On(LTR 16102B)CD-RW is perfect with the test 5 filter.

Now here's the interesting part. Apparently some CD and DVD drives are not capable of proper playback. Avih and I spoke for quite some time over IRC tonight and tried several things. I gathered up 7 various drives around the house, most of which are less than a few years old, some are much newer. Here is what w tried-

1. Use CloneCD 4.0 b30 to make an image(CCD) from the Samsung 16x DVD-ROM drive. This drive refused to play the movie directly from the CD with any software player. CloneCD however had no problems ripping it to the local hard disk at 32x. I mounted the image with Daemon Tools 3.x and played the file fine. Samsung drive has latest firmware as well thanks to Neo Neko :-)

2. I also tried several different ASPI installs on the Windows XP system with all the drives. Versions 4.60, 1.23 and 4.70 were installed to the system. As well, Avih had me try each of the DLL's in the actual software players folder(ie. PowerDivx4).

3. Tried an I/O Magic 8x DVD-ROM. Same problems, no playback at all but CloneCD could image the CD fine. Drive has been updated with latest firmware also.

4. Playback with Phillips 4801 CD-RW worked perfectly as well.

5. Playback on Acer 50x CD-ROM worked flawlessly as well.

6. Tried a Mitsumi CR-4804TE CD-RW and it would not playback the CD either. This drive is somewhat older though.

7. I'm too tired to mention the other drives that were tested. They were just generic 32x CD-ROM drives that played back the CD fine.


So here's my point...has anyone managed to playback one of these discs on a DVD-ROM drive? At least for me the pattern seems to be both of my DVD drives refuse to read the disc.

@DeXT
You mentioned on IRC tonight that you had found Samsung drives to be problematic with M2F2 disc. Where you talking about the DVD drives or just the opticals in general?

Thx in advance for the feedback.

Edit- All the latest filters and CD maker tools were used. CDRWIN 3.8e was used to burn the cue file to 80min Imation Silver CDR Media. The OGM image was around 814MB.

[TheXung]

Toshiba 12x DVD rom does not reconize the disc.

[Peters]

Report

Made several tests

- OS: WinXP
- Storage: 700 Mo CD-RW Memorex
- Burner: IDE Memorex 24x
- Media 800 Mo OGM
- Burning prog Nero 5.5.7.2
- DVD Drive IDE Hitachi GD-8000

Burning Speed 10x

Always playback with success, seeking fine.
I let playing the whole movie to be sure, no error

Edit: to complete information with Nero InfoTool http://www.cdspeed2000.com/files/NeroInfoTool_101.zip

Drive Information
-----------------
Drive : HITACHI DVD-ROM GD-8000
Type : DVD-ROM Drive
Firmware Version : 0005
Buffer Size : 512 KB
Date : ?
Serial Number : ?
Drive Letter : H:\
Location : 1:1
Mechanism : Tray
Read Speed (Max.) : 40 X
Write Speed (Max.) : n/a

Read CD Text : Yes
Return C2 Pointers : No
Read CD-R : Yes
Read CD-RW : Yes
Read DVD-ROM : Yes
Read DVD-RAM : Yes
Read DVD-R : Yes
Read DVD-RW : Yes
Read DVD+RW : Yes
Read Digital Audio : Yes
Read CD+G : No
Read VideoCD : Yes

Write CD-R : No
Write CD-RW : No
Write DVD-R : No
Write DVD-RW : No
Write DVD+RW : No
Write DVD-RAM : No
Buffer Underrun Protection : No
Mount Rainier : No
Modes : n/a

Region Protection Control : RPC II
Region : 1
Changes User : 1
Changes Vendor : 4

[avih]

@Peters: thx. that's cool indeed.

@others:
i've heard more than one person complaining that the 800M cd doesn't work on dvd drives (or on plain cd-rom drive) (obviously peter shown that it is possible to play from, at least some, dvd drives), so i would ask to report about the following scenario if possible:

regarding BOTH standard CD-ROM drives and DVD drives:

1. does the drive play the 800M file?
2. if not, can it read cd-r from the same manufacturer and type that were burned 'normally'? (i.e. using easy cd creator or other software for making a 'standard' compilation)
3. any cd-rw experience (media) is welcome as well (we had reports it was working for some).

thanx
avi.

@dext: i've read this thread about some vcd problems, (http://forum.doom9.org/showthread.php?s=&threadid=24239)
could it be here as well? ( i guess it could, but i'd find it strange if the drive is able to play 'standard compilation' medias and not 800M medias, while both from same manufacturer and model). any idea??

[Demone]

BIG SUCCESS HERE !!!
Me and ErMonnezza succesfully made a 900mb avi on a 'ThatsWrite 90min'
with LiteOn 16x burner.

The problem is that its difficult to read, I mean it seems that the burn process was succesfull, but only the burner used and an LG-CD reader were able to playback it:

*LiteOn 16x burner(the one used to burn the disc)=need time before start and make some rumors but plays 'QUITE' well.

*Yamaha 8424e burner = CANT READ + NOISES

*PioneerDVD reader without slotin = CANT READ + NOISES

*PioneerCD reader with slotin = CANT READ + NOISES

*Samsung SC-148C = CANT READ + NOISES (more about this later)

*LG CRD-8400B = NO RUMORS PLAYS OK

Now this can all depends on media type, but I noticed that the samsung
cant read overburned cds, cause I tried 705 minutes and they didnt worked at all (different brands too), the LG, that is a brand that I personally dont give a cent to, worked ok. The good news is that apparently the filter can go up 900mb without problem.
A normally burned CD (800mb avi) worked ok on all the listed drives.

[oddball]

Going a bit off topic with the oversized CD-R's. I noticed that burning 99 min Infiniti media on a LiteOn 24x close to it's full 900MB resulted in not all data being read back on the LiteOn (Even though it reported burning successfully in Nero latest) and on a Pioneer 116 DVD-ROM drive. I find that anything over 850MB is risky. So if anyone plans on using this for burning 99 min M2F2 CD-R I would STRONGLY recommend against it. Or at least only burn up to around 950MB M2F2 on 99 min.

The Pioneer physically hits the heads against it's limit when trying to read back the full 99 min capacity. The LiteOn just whirs and never reads the end data. Not tried M2F2 on 99 min yet so your mileage may vary. But since this is beyond the scope of all the legitimate ISO formats it's risky to try. I certainly would not trust any movies I want to keep to it.

[int 21h]

This reminds me that I once tried imaging SVCDs with CloneCD for copying, and it failed... miserably. The cds never came out readable. However, when I imaged with CDRWin and burnt, they were fine. I would burn the cdrwin image generated by the tool, and then use that CD to test.

Originally posted by MaTTeR
Ouch, this thread is almost ready to split:)

Just wanted to post some of the testing I've done over the past 4hrs or so:confused: I've successfully created several large Ogg file with Vorbis audio and burnt them. The playback on the Lite-On(LTR 16102B)CD-RW is perfect with the test 5 filter.

Now here's the interesting part. Apparently some CD and DVD drives are not capable of proper playback. Avih and I spoke for quite some time over IRC tonight and tried several things. I gathered up 7 various drives around the house, most of which are less than a few years old, some are much newer. Here is what w tried-

1. Use CloneCD 4.0 b30 to make an image(CCD) from the Samsung 16x DVD-ROM drive. This drive refused to play the movie directly from the CD with any software player. CloneCD however had no problems ripping it to the local hard disk at 32x. I mounted the image with Daemon Tools 3.x and played the file fine. Samsung drive has latest firmware as well thanks to Neo Neko :-)

2. I also tried several different ASPI installs on the Windows XP system with all the drives. Versions 4.60, 1.23 and 4.70 were installed to the system. As well, Avih had me try each of the DLL's in the actual software players folder(ie. PowerDivx4).

3. Tried an I/O Magic 8x DVD-ROM. Same problems, no playback at all but CloneCD could image the CD fine. Drive has been updated with latest firmware also.

4. Playback with Phillips 4801 CD-RW worked perfectly as well.

5. Playback on Acer 50x CD-ROM worked flawlessly as well.

6. Tried a Mitsumi CR-4804TE CD-RW and it would not playback the CD either. This drive is somewhat older though.

7. I'm too tired to mention the other drives that were tested. They were just generic 32x CD-ROM drives that played back the CD fine.


So here's my point...has anyone managed to playback one of these discs on a DVD-ROM drive? At least for me the pattern seems to be both of my DVD drives refuse to read the disc.

@DeXT
You mentioned on IRC tonight that you had found Samsung drives to be problematic with M2F2 disc. Where you talking about the DVD drives or just the opticals in general?

Thx in advance for the feedback.

Edit- All the latest filters and CD maker tools were used. CDRWIN 3.8e was used to burn the cue file to 80min Imation Silver CDR Media. The OGM image was around 814MB.

[spectra]

Originally posted by avih

@others:
i've heard more than one person complaining that the 800M cd doesn't work on dvd drives (or on plain cd-rom drive) (obviously peter shown that it is possible to play from, at least some, dvd drives), so i would ask to report about the following scenario if possible:

regarding BOTH standard CD-ROM drives and DVD drives:

1. does the drive play the 800M file?
2. if not, can it read cd-r from the same manufacturer and type that were burned 'normally'? (i.e. using easy cd creator or other software for making a 'standard' compilation)
3. any cd-rw experience (media) is welcome as well (we had reports it was working for some).

thanx
avi.

so my former sucess report was a
791 MB Dat file (782MB DivX5 avi) burned on a
Verbatim 700MB CD-RW 10x (No.43147) using a PlexWriter 40/12/40 writing with 12x speed (CDR-Win 3.8).

Reading:
PlexWriter 40/12/40 > perfect
Plextor UltraPlex32 > perfect
PioneerDVD 105slot over network > perfect

[Teegedeck]

You seriously want to collect test results in this thread? Here is some from my first test:

796 MB .avi-file -->
804 MB .dat file

Burned OK with Nero on a LiteOn 24102B (writing at 24x),using no-name-brand 700-MB-media.

The resulting XCD was readable on my Toshiba SD-M1212 DVD-ROM (EDIT:...and on the LiteOn-CDRW,too). The .avi (XviD + VBR MP3) plays perfectly.

BTW, thanks to all of you developers on that XCD-project.


EDIT: model- & firmware nrs.(I had a typo in the LiteOn model-nr before):
Toshiba DVD-ROM SD-M1212, Firmware"1R14"

The Toshiba is from 2000, I believe, never did a firmware-update, the LiteOn's is about half a year old.
LiteOn LTR24102B, Firmware "5S07"

[DeXT]

Let me summarize all the reports we have got so far.

80 min media:

Success:

Creative 1240E DVD
Hitachi GD-8000 DVD
LG DVD (model?)
Lite-On 12101B (LS3J) CD-RW
Lite-On 16101B CD-RW
Lite-On 16102B CD-RW
Lite-On 24102B (5S07) CD-RW
Phillips 4801 CD-RW
Pioneer 105S DVD
Pioneer 116 DVD
Pioneer 305S DVD
Plextor UltraPlex32 CD-ROM
PlexWriter 40/12/40 CD-RW
RICHOH MP7163A CD-RW
Samsung CD-ROM (model?)
Toshiba SD-M1212 (1R14) DVD
Yamaha 2100S (1.0N) CD-RW
Generic 32x CD-ROM (several brands)

Failure:

Acer 50x CD-ROM
I/O Magic 8x DVD
Mitsumi CR-4804TE CD-RW
Samsung 16x DVD
Toshiba 12x DVD


90 min media:

Success:

Lite-On 12101B (LS3J) CD-RW (with difficulty)
LG CRD-8400B

Failure:

Yamaha 8424e CD-RW
Pioneer 116 DVD
Pioneer CD-ROM (model?)
Samsung SC-148C


It's pretty strange we have two antagonic reports regarding the Toshiba 12x DVD drive. I wonder if they are the same model or not. If that's the case it could be due to different factors such as the media type used or the burning speed. Oh and about the 90 min reports it seems the failures are not really related to the m2f2 reading but mostly to the media compatibility.

[Edit]

New information regarding this issue. I had an old 24x CD-ROM which was not able to read ANY kind of S/VCD under XP. But when I tested it under Win98 I had no problems at all reading the same CDs. So it seems this could be due to some kind of OS issue (probably a "bug" or a "feature" in NT/2K/XP CDFS.SYS), and not really a hardware issue.

So perhaps this Toshiba 12x antagonic report could be due to this (i.e. the same drive under different OS).

[MaTTeR]

Perhaps it would be good if those that are submitting reports might also mention which firmware revision they have on the drive. I would always suggest having the latest firmware installed.

[ChristianHJW]

Originally posted by Teegedeck
796 MB .avi-file -->804 MB .dat file
The .avi (XviD + VBR MP3) plays perfectly.

AVI ? .. time for a change old friend, dont you agree ;) ?

[Teegedeck]

I'm still waiting for MCF, dear! :b

[Sygma21]

I report success about 799 Mo OGM/Xvid/vorbis 128knps.

Burner : Yamaha 2100S (1.0N)
DVD : Pioneer 305S
OS : W2K SP2
Soft : CDRWIN 4.0a (with CUE)
CDR : Samsung 80mn 16X
Player : WMP6.4, Zoomplayer
Last mode2cdmaker & CDXAtest5

Nota: My previous CD made with old versions works fine with new CDXA DS filter

Regards

[spyder]

@DeXT: You can add Lite-On 16101B to that list. My Creative 12x DVD drive (1240E) has no problems reading either.

[philippas]

Success also on several cd's
Write:RICHOH MP7163A, burned with Nero
Read: LG DvD-Rom, Samsung Cd-Rom
Os: winXp

[DeXT]

Ok, stuff updated, thanks guys.

BTW read my new comment about the XP issues with some drives. This may bring new light to this problem.

[ErMonnezZa]

Ok here my results:

cd 80 min media:

Lite-On 12101B firmware LS3J--------------->ok
Pioneer DVD-ROM DVD 116-------------------->ok

CD 90 min media

Lite-On 12101B firmware LS3J------------->sometimes work with difficulty

Pioneer DVD-ROM DVD 116------------------>Doesn't work

[DeXT]

For those interested, here you have the theoretical max. capacities for each type of media:



+--------+--------+--------+--------+
| 74 min | 80 min | 90 min | 99 min |
+-----------+--------+--------+--------+--------+
| Mode 1 | 650 MB | 703 MB | 791 MB | 870 MB |
+-----------+--------+--------+--------+--------+
| Mode 2 | 738 MB | 798 MB | 897 MB | 987 MB |
+-----------+--------+--------+--------+--------+

Of course this depends on media, since many CD brands has sightly more capacity than the "standard" one.

(moved from the XCD thread since it fits better in this one)

[kxy]

It will be useful if we can burn the extra files(subtitles, images, etc) on to the CD. I tried adding the subtitle files (*.idx, *.sub) to the cd, but it didn't work, the cd turn out to be unreadble. This is what I did. First I burn the extra files first with (DAO leave the session not closed), then I burn the image file using CDRDAO, it reported the writing successfully, but it won't read. I also tried session at once, it didn't work either.

Is this cause by the padding zeroes at the end?

Has anyone tried that with success?

EDIT: My burner is LTR-24102B, winxp

[DeXT]

You cannot add files to an existing session this way. You must activate Multisession and create an open session after writting the first one ("Open New Session"). Then you can add a second session with a Multisession-aware program (I guess CDRDAO isn't; use Nero or the like). Anyways I haven't tried this and I'm not sure if it can be done with VCD-like images.

In any case this isn't needed once I add Form1 files support to mode2cdmaker (soon to come). Meanwhile you can mux the subtitles along with your movie in an OGG media file and burn it with my tool.

[mustaneekeri]

I must say that I would like to have form1 files in XCD. I have done my earlier rips so that they also contain external sub files, player(BSPlayer), CDautorun program, DVD-cover .jpg. When this possibility becomes available i will start using XCD. Anyway im using 99min CDs and im really waiting to put 980Mb .ogm file in to one. :D

[kxy]

Originally posted by DeXT
You cannot add files to an existing session this way. You must activate Multisession and create an open session after writting the first one ("Open New Session"). Then you can add a second session with a Multisession-aware program (I guess CDRDAO isn't; use Nero or the like). Anyways I haven't tried this and I'm not sure if it can be done with VCD-like images.


You can't, because Nero or other Multisession-aware programs would only take 700mb for a 80min CD. That is why I burn the misc files first.

Waiting for the new form 1 files. :D

[avih]

Originally posted by mustaneekeri
I must say that I would like to have form1 files in XCD. I have done my earlier rips so that they also contain external sub files, player(BSPlayer), CDautorun program, DVD-cover .jpg. When this possibility becomes available i will start using XCD. Anyway im using 99min CDs and im really waiting to put 980Mb .ogm file in to one. :D

There is no XCD yet ok?. dext's tool and the filter are completely general, therefore i would refrain from calling anything XCD atm simply because it will confuse ppl. To have a look at the initial XCD specifications, check out http://xcd.sf.net (and do keep in mind 1. it's not final, 2. we have more plans that we didn't put into the page yet (this page was last modified few days ago).

about the arbitrary binary files: there would be such thing. i'm not sure though , that it would be able to store subtitles that way since the playback bay be skippy if the player has to use two different streams throughout the entire clip. copying it to the HD is an option, but then stand alone players may have problems with it. i'd suggest using subtitles that are embeded into the main stream, like in ogg (or mcf when it's ready).

cheers
avi

[spyder]

avih & DeXT:

I have nearly completed a prototype of a reader for the XCD header files to splice in backup sectors when reading from an XCD stream file(Don't worry it's completely open to modification not final). In the process I noticed that in the spec you used UINT64, I'm assuming that means an unsigned 64 bit integer. Why such extreme size? It's only 8 bytes I know but 8 bytes could make a huge difference in a hardware player. 64-bit numbers can reference up to 17179869184 GB of data. I don't think we will have a disc of that capacity in the life span of XCD. Why use 64-bit?

[avih]

spyder, do you know what 'initial' and 'draft' means? it means it's the 1st version, and that's it's far from beeing finalized. i just wrote this document so we can have a framework to work with. there won't be probably a single definition that will stay till the 1st minimal spec.

i suggest not writing XCD readers yet since the XCD header format is REALLY REALLY REALLY far from beeing finalized. (i.e. we'll add support for a situation where the whole file is a backup, so the stream file itself won't be there at all (there'll be a bit in the header somewhere), and an offset of the 1st actual backup to the header such that if we decide to add 'content' to the header before the actual backups, players that were designed today will still be able to play files that will be recorded next year.

the work on the tools and filters so far (mode2cd) is completely general and the lessons learned will be implemented in XCD, but it's not xcd.

regarding 64Bits: my initial thought were not to limit the size of the file or the media type. 32 bits give us 4G, but tomorows media might contain 100G. these 64 bit values are very sparse throughout the cd, so there's no space problem if storing as 64 instead of 32 bits.

spyder, i suggest that instead of start programming a 'compliant' reader, start to think how to imrove the spec. pls especially keep in mind the last paragraph from the main xcd page:

XCD is currently in it's planning stage. Our 1st priority task is finilizing a minimal specification that will be sufficient to play the files, while beeing extensible, such that future versions of the specifications won't break compatibility with players that support only this minimal specifications.

cheers
avi

[avih]

spyder: i'm not trying to de-motivate you here. i just think that the minimal spec should be finalized before we 'jump' into implementations. start implementations while the minimal spec is not finalized is doing efforts in vein. i'm just trying to focus the development.

the work we're doing now with the filter and tool is essenitial to learn more about filter and image issues.

so i think the only help needed atm with regard to xcd is to think how to achieve the main goal of minimal spec.

:) ok? sorry if i seemed too harsh on you. i appologise.

cheers
avi

[spyder]

avih:

As I said, I understand that the spec is initial. I was not saying I was writing an XCD player or releasing an XCD reader class. I am just writing a minimal implementation to test what already has been specified and to help identify any issuse there may be in the current draft. It is not taking long to implement this, only a few more lines of code added to what I already had and I can add support for backed up sectors. I am not shooting forward with development, I was just trying to determine how well the initial spec will hold up later on.

[ChristianHJW]

XCD <---> MCF
avih <---> Tronic
spyder <---> ChristianHJW


@avih : you sound like Tronic my freind :D ... '...no, lets finalize the specs first, then we go making first muxers/parsers..' .....

@spyder : i'd love to have some first tools to play with, just because i fully believe that the best way to improve specs is to play around and get experience, so you will notice some problems and improve the specs thereon.

avih wrote :i'd suggest using subtitles that are embeded into the main stream, like in ogg (or mcf when it's ready).

I fully agree. In fact i was surprised to hear that there will be subtitle and chapter specs for XCD ... whats the purpose ? In real life these information will always be in the container ( AVI, OGM, MP4, MCF, QT, whatever ..) i guess ? Did i miss soemthing ?

[avih]

XCD <---> MCF
avih <---> Tronic
spyder <---> ChristianHJW


@avih : you sound like Tronic my freind ... '...no, lets finalize the specs first, then we go making first muxers/parsers..' .....


ROTFL ;)

ps.
atm, i don't think that XCD will have subtitles and/or chapters spec because XCD is a META-container. that means that it doesn't care about stream container/content itself, but rather cares about a higher level. i.e. how do we put the streams on cd, how do we make a playlist of different streams, menus (dividivx?? ;)) etc. the stream container/content (+subtitles or any other parts) are the stream's responsibility. XCD will just define a method for storing such streams.

cheers
avi

[spyder]

Christian:

I am glad you get my point. You may never know how well a spec stands up until it is implemented and then you have to rethink your spec all at once when something needs fixed or added. Why didn't DeXT and avih think up the entire spec and then create the programs to create these image files? Because they might waste a whole lot of time and it not work to their expectations. Of course my work will be limited because I am only fluent enough in Java. I have always wanted to learn C++ but I can't get used to all the Windows crap. I can program in basic C++ but I never learned much because I hate M$ software and I do not use Linux for enough things to bother learning it(which I would much rather do). I need to find the source for a Java MPEG-1/2/4 player(all welcome). If anyone finds one of these please e-mail me about where I can find it. My address is spyder482@yahoo.com

On the subject of subtitles and chapters, I believe these should be included in the container format also. MCF might want to be able to index external subtitle files but they do not need to be M2F2 anyway. But that should not need to be a part of XCD. I believe the best way for XCD to go is to remain as open as possible to many different kinds of containers while preserving the basic architecture for simplicity.

[DeXT]

Hi there spider. I searched for "java mpeg" in Google and got some interesting results:

http://peace.snu.ac.kr/dhkim/java/MPEG/
http://rnvs.informatik.tu-chemnitz.de/~ja/MPEG/MPEG_Play.html
http://www.javazoom.net/javalayer/javalayer.html
http://www.dcc.uchile.cl/~chasan/MPEGPlayer.zip

IBM will release its Java MPEG-4 player once the MPEG-4 license model is finished.

Great work... ;)

[spyder]

DeXT:

Thanks for the links I will look at the MPEG video players later. The JavaLayer one is to the program I have already modified(look at the earlier posts) IBM had already released their MPEG-4 code but they withdrew it because of license issues and haven't put it back yet.