ffdshow tryouts project: Discussion & Development

[clsid]

Can't you also add detection of the "AVI splitter" filter so no filename check is needed at all?

[haruhiko_yamagata]

Can't you also add detection of the "AVI splitter" filter so no filename check is needed at all?
There are several AVI splitters that are familiar to us and there may be some other AVI splitters.

[ipanema]

If it is a file, please set file name in FILTER_INFO::achName. But if it is a live stream, it does not have file name and extension.

Now ffdshow parses access units if the file name extension is NULL.


I'm a little confused by your explanation. If ffdshow parses access units if the file extension is NULL, then this seems to be what I need because the stream I deliver does have 00 00 00 01 09 sequences, and they MAY occur in the middle of a directshow sample.

Does that mean I can just hard code FILTER_INFO::achName to be something like

"dummy"

This has no file extension, and it sounds like ffdshow does not need to know the actual filename - it is just looking for the absence or presence of a filename extension.

This would seem to be safer than specifying the full pathname of the file with its extension because I don't know what specific filename extensions ffdshow might be checking for - it might do different things depending on the filename extension.

Also do you mean that "Now ffdshow parses access units if the file name extension is NULL" has already been implemented or that it will be implemented in a future revision?

How are you reading the FILTER_INFO::achName ? Are you just getting the upstream filter and calling QueryFilterInfo() on it? I ask because you said a a while back that you would need the filter GUID, but I think you can get the upstream filter without having to know its GUID in advance via IPin::QueryPinInfo() on the upstream connected pin.

[haruhiko_yamagata]

I'm a little confused by your explanation. If ffdshow parses access units if the file extension is NULL, then this seems to be what I need because the stream I deliver does have 00 00 00 01 09 sequences, and they MAY occur in the middle of a directshow sample.

Does that mean I can just hard code FILTER_INFO::achName to be something like

"dummy"

This has no file extension, and it sounds like ffdshow does not need to know the actual filename - it is just looking for the absence or presence of a filename extension.
If you want to support current and older (say, beta 6) ffdshow, please use "dummy.ts".

This would seem to be safer than specifying the full pathname of the file with its extension because I don't know what specific filename extensions ffdshow might be checking for - it might do different things depending on the filename extension.

Current ffdshow (not my local working copy) compare extension with
ts, m2ts, m2t, mts, mpg, mpeg.
So it's safe to specify Drive:\path\filename\extension.

The new version will compare extension with avi.

Also do you mean that "Now ffdshow parses access units if the file name extension is NULL" has already been implemented or that it will be implemented in a future revision?
In the near future, this week probably.

How are you reading the FILTER_INFO::achName ? Are you just getting the upstream filter and calling QueryFilterInfo() on it?
Yes.

I ask because you said a a while back that you would need the filter GUID, but I think you can get the upstream filter without having to know its GUID in advance.
I don't seem to require your filter's GUID for now, but I required NeuviewSource's GUID for the workaround.

[ipanema]

The upstream filter from the ffdshow filter is the MPEG-2 demux, so I set the FILTER_INFO::achName of the demux and also of my source filter by calling AddFilter specifying a filter name ending in ".ts" - for example:

m_pGraph->AddFilter(pDemux, L"Demux.ts");

Unfortunately this makes no difference. The Source File is still shown as blank and the decoded frames are still corrupted.

I'm setting up the media type WITH the dwSequenceHeader (SPS and PPS) and the main media type structure set as posted earlier.

P.S. I'v just tried to query the achName of the Demux from my source filter (the opposite direction to which you'll be looking from the ffdshow filter) using the following code:

CComPtr <IPin> nDemuxInPin;
pSourceOutPin->ConnectedTo(&nDemuxInPin);
PIN_INFO pininfo;
nDemuxInPin->QueryPinInfo(&pininfo);
CComPtr <IBaseFilter> pDemuxFilter = pininfo.pFilter;
FILTER_INFO filterinfo;
pDemuxFilter->QueryFilterInfo(&filterinfo);

and the filterinfo.achName does indeed read "Demux.ts"

[haruhiko_yamagata]

The upstream filter from the ffdshow filter is the MPEG-2 demux, so I set the FILTER_INFO::achName of the demux and also of my source filter by calling AddFilter specifying a filter name ending in ".ts" - for example:

m_pGraph->AddFilter(pDemux, L"Demux.ts");

Unfortunately this makes no difference. The Source File is still shown as blank and the decoded frames are still corrupted.

I'm setting up the media type WITH the dwSequenceHeader (SPS and PPS) and the main media type structure set as posted earlier.

P.S. I'v just tried to query the achName of the Demux from my source filter (the opposite direction to which you'll be looking from the ffdshow filter) using the following code:

CComPtr <IPin> nDemuxInPin;
pSourceOutPin->ConnectedTo(&nDemuxInPin);
PIN_INFO pininfo;
nDemuxInPin->QueryPinInfo(&pininfo);
CComPtr <IBaseFilter> pDemuxFilter = pininfo.pFilter;
FILTER_INFO filterinfo;
pDemuxFilter->QueryFilterInfo(&filterinfo);

and the filterinfo.achName does indeed read "Demux.ts"
Sorry, I found ffdshow is using IFileSourceFilter::GetCurfile.
ffdshow searches to the upper stream and find the source filter.const char_t* TinputPin::getFileSourceName(void)
{
IFilterGraph *graph=m_pFilter->GetFilterGraph();
if (!graph || wasGetSourceName || !filesourceFlnm.empty())
return filesourceFlnm.c_str();
wasGetSourceName=true;
comptr<IBaseFilter> filter;
if (searchPrevNextFilter(PINDIR_INPUT,this,this,&filter,TpinFileSourceComp()) && filter)
{
comptr<IFileSourceFilter> ifsf;filter->QueryInterface(IID_IFileSourceFilter,(void**)&ifsf);
LPOLESTR aviNameL=NULL;
ifsf->GetCurFile(&aviNameL,NULL);
if (aviNameL)
{
filesourceFlnm = text<char_t>(aviNameL);
CoTaskMemFree(aviNameL);
}
else
filesourceFlnm=_l("");
}
return filesourceFlnm.c_str();
}

struct TpinFileSourceComp
{
bool operator ()(IBaseFilter *bff,IPin*) const
{
comptr<IFileSourceFilter> ifsf=NULL;
return SUCCEEDED(bff->QueryInterface(IID_IFileSourceFilter,(void**)&ifsf)) && ifsf!=NULL;
}
};

Please implement IFileSourceFilter.
Thank you for your consideration of this matter.

[ipanema]

Haruhiko, that works fine now. :)

Thankyou for looking into this.

"Now ffdshow parses access units if the file name extension is NULL"

By NULL do you just mean a filename without an extension - e.g. "myfile" or "myfile." ?

[haruhiko_yamagata]

Haruhiko, that works fine now. :)

Thankyou for looking into this.



By NULL do you just mean a filename without an extension - e.g. "myfile" or "myfile." ?
Yes, ffdshow parses access units if the file name does not have extension or IFileSourceFilter is not implemented.

[ipanema]

Now that this seems to be working, here's an observation.

Most of the time ffdshow does not seem to decode the 2 B frames that preceed the first I frame (in presentation order) in the stream. It does seem to do this most of the time at the start of a file but if you start streaming data from an I-frame located elsewhere in a file then the 2 preceding B frames are not decoded (as if it was an open GOP). But Mainconcept always seems to decode the 2 preceeding B frames no matter which I-frame in the file you start streaming from (as if all GOPs were closed).

Do you know what flags in the stream the ffdshow's H.264 decoder is using to decide not to decode the 2 leading B frames? And is it making a mistake? If Mainconcept can perfectly decode these B frames OK then surely ffdshow should be able to aswell.

[therealjoeblow]

Improving AutoCrop before releasing beta 7 would be nice. But since it was broken before, not a requirement.


I'm not sure if it's even possible so please forgive me if not, but if anyone's going to be working on AutoCrop, what I've been longing for is for AutoCrop to be able to determine the actual image's height (I believe in the same standard way it currently does), and then crop the sides off to as close to a true 16:9 image as it can (a modification to the code would be necessary for this variation).

The reason is that I have a plasma display used exclusively for movies, and to avoid uneven screen wear and potential burn-in, I don't want the black-bars displayed on 2.35:1 or anything wider than 16:9. Right now I use ZoomPlayer to manually zoom the image for extra-widescreen movies, but it's not automatic. Having a variation of AutoCrop that could do it automatically would be great if possible!

[Komano]

Hello Guys, I have been having problems with S/PDIF and if you need me to test the S/PDIF Fixes, i can help. PM me or something?

[Snowknight26]

There appears to be a bug in libavcodec where FRAPS videos have the right-most 16 pixels a different level, or so it appears. Doesn't happen when using decoder that comes with FRAPS but does with libavcodec.

Sample source: http://stfcc.org/misc/epiczip.zip (disregard the other files)
Sample encode from source using libavcodec: http://stfcc.org/misc/fraps.libavcodec.mkv

http://i39.tinypic.com/11qqqkx.png

[Casshern]

Hi,

the Dolby Tru HD decoder works well with the latest releases. Also nice is that when you turn it off, ffdshow extracts the ac3 core and sends that over sp-dif. So far, so good. But some Dolby Tru HD tracks lack an ac3 core. In this case the preferred behaviour would be:
1) If ac3 core of a dolby tru hd track is available send that over sp-dif
2) if ac3 core is not available use the dolby tru had decoder

All that would be required would be an option on the dolby tru hd decoder like "Only use if no ac3 core is detected"

The reason for all this is, that many people got receivers only supporting ac3 and dts. Here it is nicer to have the ac3 core, than to decode and reencode or even than to use the analog outs.

[Gleb Egorych]

There is a problem with ffdshow and DVBViewer. Looks like a bug in DVBViewer source filter that confuses ffdshow (from beta6 to r3004).

On mono channels (MPEG2 video + MP2 audio) with DVBViewer I had no sound, so I made a discovery and supposed that DVBViewer sent wrong channel number to decoder.
I tested all available options for MP2 decoding, here are the results:

libmad: detects input as stereo and gives no output, info page is blank.
mp3lib: detects input as stereo and outputs as stereo.
libavcodec: detects input as mono and outputs as mono.

Looks like libavcodec is the most foolproof, but by default libmad is used for MP2. So I believe libmad has higher quality (?).

It can be fixed within DVBViewer, the option is called "TV/Radio Pre-Format Detection".

[Gleb Egorych]

Question about presets:
I tried to setup ffdshow specially for ReClock, made a preset with autoloading condition "on a DirectShow filter presence"="ReClock Audio Renderer", but ffdshow all the same uses default preset. Also tried "*ReClock*" with no luck. Does the condition work only for filters before ffdshow?

Using rev2940

[Leak]

Question about presets:
I tried to setup ffdshow specially for ReClock, made a preset with autoloading condition "on a DirectShow filter presence"="ReClock Audio Renderer", but ffdshow all the same uses default preset. Also tried "*ReClock*" with no luck. Does the condition work only for filters before ffdshow?
Yes, as autoloading conditions are only checked when ffdshow is inserted into the graph, which usually happens before audio and renderer filters are added.

[leeperry]

Also tried "*ReClock*" with no luck. Does the condition work only for filters before ffdshow?
you'd be better off using one specific player for Reclock and make a ffdshow preset depending on its .exe name

[Gleb Egorych]

Yes, as autoloading conditions are only checked when ffdshow is inserted into the graph, which usually happens before audio and renderer filters are added.
Maybe this behaviour should be changed (if possible). Strange situation: filter exists, name is correct, rule does not work.
you'd be better one using one specific player for Reclock and make a ffdshow preset depending on its .exe name
Already done, it was the only option. Now I have mplayerc_rc.exe with mplayerc_rc.ini for ReClock.

[haruhiko_yamagata]

There appears to be a bug in libavcodec where FRAPS videos have the right-most 16 pixels a different level, or so it appears. Doesn't happen when using decoder that comes with FRAPS but does with libavcodec.

Sample source: http://stfcc.org/misc/epiczip.zip (disregard the other files)
Sample encode from source using libavcodec: http://stfcc.org/misc/fraps.libavcodec.mkv

http://i39.tinypic.com/11qqqkx.png
ffplay has the same issue. Please report it directly to FFmpeg.

[haruhiko_yamagata]

Now that this seems to be working, here's an observation.

Most of the time ffdshow does not seem to decode the 2 B frames that preceed the first I frame (in presentation order) in the stream. It does seem to do this most of the time at the start of a file but if you start streaming data from an I-frame located elsewhere in a file then the 2 preceding B frames are not decoded (as if it was an open GOP). But Mainconcept always seems to decode the 2 preceeding B frames no matter which I-frame in the file you start streaming from (as if all GOPs were closed).

Do you know what flags in the stream the ffdshow's H.264 decoder is using to decide not to decode the 2 leading B frames? And is it making a mistake? If Mainconcept can perfectly decode these B frames OK then surely ffdshow should be able to aswell.
They are simply dropped without any flags. It's a bug then. I'll re-read the spec and think about the fix.

[leeperry]

I was wondering, is there a way to decode MP3 in a DivX/AVI file w/ ffdshow audio at all? I keep getting an "ACM wrapper" in my graph files....even w/ using HMS :confused:

apparently MP3 in an AVI container has to go through ACM? only MPC's Audio Decoder fixes the problem...but I still can't seem to be able to use ffdshow's MP3 decoder w/ AVI files :o

[clsid]

That normally works fine. Perhaps the audio in your file is stored in an unusual way. Otherwise is is just user fail :)

[albain]

Autocrop feature
Description : autocrop is a feature included in the crop filter of FFDShow that scans and removes the black borders (vertical, horizontal, or both).
The scan is performed each x milliseconds (delay parameter), and the scan is stopped once one considers that the analysis is done (stop parameter, after 100 seconds usually it is okay, after the logos, warnings,...).
There is a tolerance parameter (the one that needs to be tuned) that lets tune the scan according to the video quality and the difference of luminance levels between the bars and the real picture.
Also, once the scan has reach a highwater level, the crop won't be increased anymore, only decreased : the reason is simple, if black bars are detected on a clear picture, and after this clear picture there is for example a dark area at the bottom for example, the autocrop won't be increased to include this dark area.
Last detail : the scan works only on colored bars (not necessarily black).

Since last time I have brought some modifications to the algorithm.

Don't forget to change the tolerance level : I used 30 for my tests and it seems to be working fine

Here is the link of the test build
FFDShow with Autocrop (http://damienbt.free.fr/ffdshow_rev3014_20090620_dbt.exe)

I am waiting for your feedbacks, thanks !

[Atak_Snajpera]

after this revision

Revision 2976 - Directory Listing
Modified Fri May 29 14:47:09 2009 UTC (3 weeks, 1 day ago) by h_yamagata

ffmpeg-mt:
DirectShow workaround for delivering the first frame without delay.
This fixes frame drops on seek.

ffmpeg-mt causes crashes during generating previews

http://img38.imageshack.us/img38/4338/new1f.th.png (http://img38.imageshack.us/i/new1f.png/)

Tested 2986 and 3008 on vista sp1

[clsid]

That should be fixed at 3013. Please test.

[Atak_Snajpera]

excellent! Can't wait for new revision :)

[clsid]

Build is online now.

[Atak_Snajpera]

thanks! Problem solved :)

[leeperry]

That normally works fine. Perhaps the audio in your file is stored in an unusual way. Otherwise is is just user fail :)
I'm on XP SP3, Gabest Audio Decoder works fine, but ffdshow doesn't ?! apparently both MPC and KMP use an "ACM wrapper" to decode MP3, they don't seem to be able to connect w/ ffdshow...I've tried several AVI splitters(HMS/Gabest/KMP/windows built-in), problem remains :

http://thumbnails7.imagebam.com/3963/c08cf039627413.gif (http://www.imagebam.com/image/c08cf039627413) http://thumbnails18.imagebam.com/3963/16b64139627414.gif (http://www.imagebam.com/image/16b64139627414)

it happens w/ any divx/mp3 AVI file and seems to be related to "WAVEFORMATEX: wFormatTag: MPEG LAYER 3(0x55)($0055)"

same problem occurs w/ MKV(using HMS)...basically I can't get ffdshow to decode mp3 in a container.

maybe I miss a source filter?! will try to find one...I guess Gabest's Audio Decoder runs its own.

PS: MpaSplitter.ax doesn't help, it won't connect to ffdshow..

[clsid]

It works fine here on XPSP3 and it has worked fine for years. There is nothing wrong with ffdshow.

Your graph contains two audio decoders, which is weird. My guess: you are playing a file with multiple audio streams. And You messed with the "multiple ffdshow instances" setting in ffdhsow audio decoder.
OR
Reclock is fucking things up.

[leeperry]

these are single audio track files, and I'm forcing ffdshow audio to EQ/volume/matrix mixing/winamp2 plugin...same happens w/o Reclock :

http://thumbnails11.imagebam.com/3963/33178a39629973.gif (http://www.imagebam.com/image/33178a39629973)

and it works w/o an ACM wrapper using the external Gabest's Audio Decoder .ax :

http://thumbnails18.imagebam.com/3963/670c8339629974.gif (http://www.imagebam.com/image/670c8339629974)

even if I allow multiple ffdshow audio instances, problem remains...care to share your DS graph please? I lack a proper MP3 source filter obviously, Gabest's Decoder seems to run its own :o

[Komano]

No one needs me to help in S/PDIF?

[clsid]

@leeperry
Upload a sample file.
Why the fuck do you think you need a MP3 source filter? You don't. Period.
Also check if you haven't accidentally disabled MP3 in ffdshow. The ACM wrapper normally only gets used if no suitable DS Filter can be found.

@Komano
Download the latest build (3013) and test it.

[netwolf]

Last detail : the scan works only on colored bars (not necessarily black).
Thank you for the updated algorithm!
One question though: aren't those borders almost always black?
Does this mean that auto-crop doesn't work in all those cases, or did I misunderstand you?

[ipanema]

They are simply dropped without any flags. It's a bug then. I'll re-read the spec and think about the fix.

OK. Incidentally, I've just noticed an ambiguity in the wording of my previous message - here it is clarified:


Most of the time ffdshow's H.264 decoder does not seem to decode the 2 B frames that preceed the first I frame (in presentation order) in the stream. It DOES seem to decode the 2 B frames most of the time at the start of a FILE, but if you start streaming data from an I-frame located elsewhere in a file then the 2 preceding B frames are NOT decoded ...

[clsid]

Thank you for the updated algorithm!
One question though: aren't those borders almost always black?
Does this mean that auto-crop doesn't work in all those cases, or did I misunderstand you?
It works on all bars that are evenly colored. So black, grey, white, blue, etc.

[netwolf]

Thank you for clarification, clsid! Good to hear :)
I was afraid that black didn't qualify as a color, that's why I asked.

[STaRGaZeR]

I found this:

When you export all settings to a .reg file before reinstalling Windows for example, when you restore them, the avisynth script you had previously is not restored. The script itself is in the .reg file, it's just not restored.

[Snowknight26]

ffdshow (r2981 using RGB32 as the output) doesn't decode MPNG properly. Colors are severely messed up (similar to an issue I reported a while back).

http://stfcc.org/misc/epiczip.zip

Steps to reproduce:
ffmpeg.exe -i "hl2 2009-06-18 14-34-56-64.avi" -vcodec png -an test.avi
Play test.avi with ffdshow
ffmpeg.exe -i test.avi -vcodec huffyuv test2.avi
Play test2.avi with ffdshow

Screenshot from test.avi:
http://i42.tinypic.com/k9crxh.png

[Komano]

ffdshow_rev3013_20090620_clsid_x64 seems to be running fine with S/PDIF working properly.
Tested with
Full HD 1080P Files with DTS and DTS-ES Audio

My System Specs are:
Windows 7 Build 7229 X64
DFI LP DK P35 T2RS + Q6600
Nvidia 8800GT
4GB Ram
and i think thats about what you need to know. Though, my PC has known (http://www.cccp-project.net/forums/index.php?topic=3599.new#new) to produce fake results. -__-"

[fastplayer]

@Komano:
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature, asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated. (http://forum.doom9.org/forum-rules.htm)

[Blight]

Question:
How does the FFDShow subtitle renderer handle multiple subtitle files?

Case sample:
"my video.avi"
"my video.en.srt"
"my video.jp.srt"

In this sample, you have an AVI video file with two external subtitle streams. One is English and the other Japanese. How do you cycle through the subtitle tracks? Is there such a mechanism. How about supporting the IAMStreamSelect interface and exposing all subs through it? Refreshing the subtitle property page for multiple sub files might also be needed.

[haruhiko_yamagata]

Question:
How does the FFDShow subtitle renderer handle multiple subtitle files?

Case sample:
"my video.avi"
"my video.en.srt"
"my video.jp.srt"

In this sample, you have an AVI video file with two external subtitle streams. One is English and the other Japanese. How do you cycle through the subtitle tracks? Is there such a mechanism. How about supporting the IAMStreamSelect interface and exposing all subs through it? Refreshing the subtitle property page for multiple sub files might also be needed.
As far as I know, ffdshow doesn't have such mechanism.
The idea is good and I accept it as feature request, but please don't expect too much as I already have too many todo.

[Komano]

Does the CCCP Project forum link count as questionable content? O_O

[Eragon4ever]

No, your files do.

[Ger]

There is a problem with ffdshow and DVBViewer. Looks like a bug in DVBViewer source filter that confuses ffdshow (from beta6 to r3004).

On mono channels (MPEG2 video + MP2 audio) with DVBViewer I had no sound, so I made a discovery and supposed that DVBViewer sent wrong channel number to decoder.
I tested all available options for MP2 decoding, here are the results:

libmad: detects input as stereo and gives no output, info page is blank.
mp3lib: detects input as stereo and outputs as stereo.
libavcodec: detects input as mono and outputs as mono.

Looks like libavcodec is the most foolproof, but by default libmad is used for MP2. So I believe libmad has higher quality (?).

With another DVB program mono channels are perfeclty detected and played with all three libraries.

I can confirm this. I have been using libavcodec in ffdshow for mp2 for a while now for this reason. libmad is silent on mono channels.

It can be fixed within DVBViewer, the option is called "TV/Radio Pre-Format Detection".

I can't confirm this though. I have had "TV/Radio Pre-Format Detection" enabled in the DirectX options for a long time and it doesn't solve the libmad/mono issue here. I tried disabling this setting as well in case that was what Gleb meant (and rebuilding the graph several times), but it doesn't matter. libmad is still silent with the live stream. Just tested again with DVBViewer 4.2.0.1beta and ffdshow build 3014.

The recorded files work though, so I can't reproduce the issue with a recording, but Haruhiko mentioned he might be able to simulate the live stream conditions.

I haven't noticed any negative side effects after switching to libavcodec for mp2, but I'm no audiophile and I have no idea if there are sound quality differences.

@Haruhiko
Since you mentioned you had few of these mono samples I made another sample (http://sharebee.com/d3567e2e).

There is also an issue with ffdshow deinterlacing with this sample (this issue can be reproduced easily with this sample in MPC-HC + ffdshow and doesn't need any live stream simulation or DVBViewer). It seems to be badly flagged so unless I enable "force bob" for hardware deinterlacing or "process frames flagged as progressive" for ffdshow software deinterlacing the interlacing is still visible.

The problem is that when I enable either of these forced deinterlacing methods the picture becomes shaky/jumpy. Notice how the animated bottles are shaking early on. Also notice how the channel logo jumps now and then. This is tested with Nvidia hardware deinterlacing and with ffdshow's yadif with double frame rate, and the shaking is there in both cases. However with MPC-HC's internal MPEG2 decoder/deinterlacer it's a steady/stable picture that looks much better than in ffdshow. I don't think it was always like this in ffdshow. I think the shaking started a few months ago.

EDIT:
Setting "Top field first" manually instead of "auto" fixes of the shaky bottles/animation in both Yadif and hardware deint. The channel logo is still flickering a bit (completely stable with MPC-HC decoder), but I guess that may just be a side effect of the Nvidia and Yadif deinterlacing methods, which are both good with scrollers/fast motion. So I guess the field order detection may have changed at some point some months ago?

[clsid]

I found this:

When you export all settings to a .reg file before reinstalling Windows for example, when you restore them, the avisynth script you had previously is not restored. The script itself is in the .reg file, it's just not restored.
I remember that in the past there were problems with exporting the avisynth script to .reg. It got garbled because it wasn't escaped properly. The workaround was to simply not export it. The proper solution was never implemented.

There should be no problems if you manually export the registry keys from Regedit.exe.
HKCU\Software\GNU\ffdshow*

[STaRGaZeR]

"avisynthScript"="LoadPlugin("W:\\\\aa\\\\bb\\\\cc\\\\dd\\\\TIVTC.dll")
tfm(order=1,mode=3)
tdecimate(mode=1)"

That's what it is in the .reg, the \\\\ were obviously not there before. Other than that the script is correctly exported as far as I can see.

[clsid]

Ok, then it is just a bug with escaping.

[Leak]

That's what it is in the .reg, the \\\\ were obviously not there before. Other than that the script is correctly exported as far as I can see.
Except for the line breaks, which are actually the culprit.

Those would need to be escaped, as regedit will read the first line as an unterminated string and the following lines as syntax errors. Escaping the line breaks as '\n' should fix that...

np: Fink - Sort Of Revolution (Sort Of Revolution)