Using DVD2SVCD for DVD output with AC3 audio

[Nick]

Has anyone with a dual core CPU tested this? I'm still on single core and there has been talk of issues w/ Kurtnoise's builds of 0.7 with multicore setups.

[ChickenMan]

I run an Intel E660 dual core and just did an avi2dvd run with your latest as in post #47 above. All ran fine and final audio appears fine but have not played the whole dvd yet.

Have now upped to the latest 512 build as above and will soon run that as well.

Also, what "..talk of issues w/ Kurtnoise's builds.." has been the main issues raised?

[Nick]

I run an Intel E660 dual core and just did an avi2dvd run with your latest as in post #47 above. All ran fine and final audio appears fine but have not played the whole dvd yet.

Have now upped to the latest 512 build as above and will soon run that as well.

Also, what "..talk of issues w/ Kurtnoise's builds.." has been the main issues raised?

From
http://forum.doom9.org/showthread.php?p=1006422#post1006422
It seems Kurtnoise's builds can crash on dual core CPU's. So if your conversion completed, clearly no crash but with stability a concern I shall retain wisodev's build for now.

[ChickenMan]

One small issue I have found today. An AVI 23.976 fps with ac3. The AC3 is extracted fine with an Extracted_audio_1.ac3. However, since there was no audio offset, there is now no Encoded_audio_1.ac3 generated. Natively, D2S always produced this Encoded_audio_1.ac3 file. Since this file doesn't exist, then authoring doesnt happen with the Muxman setup as its looking for an Encoded_audio_1.ac3.

So I'm not sure if this belongs in the AC3 thread or the Muxman thread.

Any thoughts?

[Sir Didymus]

One small issue I have found today...
Since this file doesn't exist, then authoring doesnt happen with the Muxman setup as its looking for an Encoded_audio_1.ac3.

So I'm not sure if this belongs in the AC3 thread or the Muxman thread.
Any thoughts?

In order to be sure on the matter the simplest way is to completely remove the authoring plugin (replacing the three hack.exe components with their original counterparts - Mplex, Dvdauthor and Spumux) and see what happens. If the authoring completes properly then I would say your trouble is in the domain of BatchMux...

However, I am someway doubtful about: in the BatchMux plugin the parameters (names of the audio and video files) needed for authoring are extracted from the c/l arguments passed to Mplex_hack. In case of need it is possible to include a check in the code for looking at the "Extracted..." files when the expected "Encoded..." are not there.

I am not completely happy about this possibility, since it may introduce mutual dependencies between the audio and the authoring plugins, which is not very clean as a solution...

In the ideal case, the condition to achieve would be to provide DVD2SVCD to have available the audio file(s), with the proper filename(s), if it expects to have produced such asset(s)...

@Nick. Please tell me if you think some adaptations to Mplex_hack may be useful. I will be in any case very happy to provide whatever support or contribution on the matter...

Cheers,
SD

[Nick]

@ Chickenman
Could you clarify what you are doing? I have a few questions.

- Are you using "keep source audio" on your AVI but the AC3 plugin is not producing an Encoded Audio file, or are you re-encoding the AVI's AC3 to a different bitrate?

- If you return to BeSweet for the audio instead of AC3Enc, is the Encoded_audio file generated?

-Is there an Encoded_Audio_1.log file generated when you use the AC3Enc plugin, and if so, will you post it?

@Sir Didymus
At the moment this sounds like my problem rather than yours. It may transpire it's easier for you to fix at the muxing end but what we need is mutual operability of plugins, not mutual dependency so, when Chickenman clarifies the issue he's found I'll have a look and we'll take it from there.

[manolito]

However, since there was no audio offset, there is now no Encoded_audio_1.ac3 generated. Natively, D2S always produced this Encoded_audio_1.ac3 file.

While Chickenman is probably sleeping, here's my two cents:

I think that Chickenman's statement that D2S always produces this "Encoded_audio1.ac3" file is not correct. If the audio has no offset then this file will NOT be produced by D2S.

Chickenman must have checked "Keep source audio". In this case DVD2SVCD can behave in two different ways. If the "Extracted_audio1.ac3" file has an offset, D2S will call Besweet just to correct this offset (no reencoding). The corrected file will be called "Encoded_audio1.ac3" in this case. The muxing commandline will have the correct audio file name.

If on the other hand no audio offset is detected, then D2S will not touch the extracted audio file. But D2S is smart enough to know when it comes to muxing that the audio parameter is now "Extracted_audio1.ac3".

To me it looks like both BatchMux and the AC3Enc plugin are innocent. As Sir Didymus already pointed out, Batchmux will use whatever audio file name is issued by D2S for the muxing command. And the AC3Enc plugin only gets called if audio reencoding is checked. In in this case the encoded audio file will always have the name "Encoded_audio1.mp2" (not .ac3).

Maybe an error related to resuming?

Cheers
manolito

[manolito]

And the AC3Enc plugin only gets called if audio reencoding is checked.
I have to correct myself here. Of course the Ac3Enc plugin is also called if "Keep source audio" is selected AND the extracted audio file has a delay which D2S corrects by calling Besweet.

But I just ran a couple of test encodes, and I can confirm that in this case the AC3enc7.bat also handles the situation correctly. The batch file calls Besweet with exactly the same parameters which are issued by D2S.

I also tested the other possible situations (Keep source audio checked and not checked, Extracted_audio1.ac3 with and without offset and combinations of the two), and I could not break anything.

My source was a short DVD chapter (I have no AVIs with AC3 audio), but what can be different for an AVI source?

Cheers
manolito

[ChickenMan]

Good morning everyone :)

Well manolito pretty well summed up what I did :) but further investigation this morning I found the problem, a combination of Nicks and mine.

There was an offset to the ac3 audio, BeSweet was called but was unable to find the ac3enc.dll that one of Nicks early aften installers took out by mistake and I had not replaced it. So BeSweet failed to produce the Encoded_audio_1.ac3 while D2S assumed that it had been and passed on what it thought were the correct commands to Muxman, which then fail due to missing file.

I added the ac3enc.dll to BeSweet folder and all is working fine. It appears when "Do not convert audio" is checked, D2S calls directly to BeSweet which then uses ac3enc and not aften.

EDIT: Also the link to ac3enc.dll Nick had given above is to the original ac3enc.dll v1.0 with all its compatibility and volume problems. The later ac3enc.dll v1.20 based on ffmpeg code is really preferred and is in the BeSweet 1.5b31 beta package from http://dspguru.doom9.net/

[Nick]

OK. Well, exe's are back :)
I couldn't find a cheap or freeware batch file compiler that both worked and didn't cause virus alerts. Rather than shell out for a $200 developers licence for ExeScript, I've dusted down my programming skills (BASIC > 20yrs ago, TurboPascal only 15 years ago but I can't remember any!)

A couple of minor changes in the new versions:
-Now written in FreeBASIC instead of batch script
-AC3_DVDAuthor now picks out movie length from the project file and only creates chapters up to the correct length.
-Sed.exe no longer necessary and so no longer bundled
-icon redesigned due to the old one having something resembling the DVD-Video logo in it, which it was pointed out to me could be infringing IP rights of the DVD Alliance.

The downside is I am now busy for a few weeks, so bugfixes are unlikely. I have lightly but not exhaustively tested but decided to inflict them on you to test if you wish, at your own risk. As there will probably be some issues, I suggest that you decline to uninstall previous versions during installation and I will continue for the forseeable to host the batch versions as backup. I am also hosting the BASIC source scripts for anyone interested in debugging themselves.

http://nickspage.pwp.blueyonder.co.uk/AC3ExeSetup.exe -exe
http://nickspage.pwp.blueyonder.co.uk/AC3EncSetup.exe -batch
http://nickspage.pwp.blueyonder.co.uk/ac3enc8.zip -sources

[bionic]

Cool, thanks :)
Only done a few tests with the exe versions and short clips, so far so good :)

[manolito]

Thanks Nick for the "Exefication"!

I had no time to test the new version yet (just returned from a motorcycle trip to Greece, highly recommended), but going over the sources I think there might be a problem when CCE 2.70 is used.
-AC3_DVDAuthor now picks out movie length from the project file and only creates chapters up to the correct length.
D2S cannot determine the movie length from the ECL file created by CCE 2.70, so the movie length will be 00:00:00 in the project file.

There is a workaround (which is used by the BatchMux plugin): The number of encoded frames and the frame rate can both be extracted from the project file. This way the movie length can be calculated by dividing the number of frames by the frame rate.

Cheers
manolito

[Nick]

Just done a few tests with CCE 2.70 and you are right.
Unfortunately, in my D2S Project file, both Length and Frames have a value of zero :confused:

Maybe there is somewhere else in the ini files etc that frames are shown but I cannot find it.

I think the simplest workaround for now is to just insert a line at line 50 of AC3_DVDAuthor.bas

IF mlength=0 then mlength=20000

Then if movie length is detected as zero it makes it 5½ hours, similar to what the batch file does. Even with 10 second chapters, it generated the new DVDAuthor.xml in less than 3 seconds on my machine!

Your frames/framerate solution is of course more elegant if the number of frames is reliably stored somewhere, but for AVI's at least, the Frames entry in the project file has a value of zero. If you can direct me where I should be looking, I'll code your suggestion (at some point), otherwise I'll insert the line as above, recompile and upload.

Cheers
Nick

[manolito]

I also just finished some tests with the same results.

But the workaround is pretty easy (I know because Sir Didymus used my suggestion for his BatchMux plugin).

You can extract the frame rate from the D2S project file, and the number of encoded frames is present in the ECL file. I do not recall the exact names for the relevant parameters, but there are entries for the first and the last encoded frames. In our scenario the first encoded frame is always 0, so the entry for the last encoded frame is our total frame count (Sir Didymus added +1 to this number for some reason).

This method should work for NTSC also, no matter if it is film with pulldown or pure video.

Cheers
manolito

[Sir Didymus]

Yes, I confirm the concept outlined by manolito works pretty well... :)

If it can be useful, the segment of code to extract the movie frames from the ecl file is as follow (in Mplex_hack - written in c -, after many other consistency checks...):


// checking the presence of CCE_Project_file.ecl
strcpy(TmpStr, CCEFolder);
strcat(TmpStr,"\\CCE_Project_file.ecl");

in=fopen(TmpStr,"r");

if (in==NULL)
{
fprintf (stderr,"Mplex_hack: Error opening file %s\n",TmpStr);
exit(1);
}

// looking for the lines
// encode_first=xx and encode_last=yy

while (fgets(TmpStr, 256, in)!=NULL)
{
if (strncmp(TmpStr,"encode_first=",13)==0)
{
sscanf(TmpStr,"encode_first=%I64d", &encode_first);
} else if (strncmp(TmpStr,"encode_last=",12)==0)
{
sscanf(TmpStr,"encode_last=%I64d", &encode_last);
}
}

fclose(in);

fprintf(stdout, "CCE encode_first parameter --> %I64d\n", encode_first);
fprintf(stdout, "CCE encode_last parameter --> %I64d\n", encode_last);

if (encode_first>=encode_last)
{
fprintf (stderr,"Mplex_hack: CCE parameters inconsistence\n");
exit(1);
}

// return the encoded MovieFrames parameter
return (encode_last-encode_first+1);



As you can see the program should look for the lines

encode_first=
encode_last=

to get the frame values.

The reason for adding 1 to the difference is that the above values are frame indexes...

For example in a a situation where:

encode_first=0
encode_last=999

then it seems to me the length returned should be 1000, not 999. I am right ?

As discussed in the thread of BatchMux, in case pulldown is applied, the scaling --> length * 5 / 4 should be applied in order to obtain the right number of presentation frames from the encoded frames.

Cheers,
SD

[manolito]

As discussed in the thread of BatchMux, in case pulldown is applied, the scaling --> length * 5 / 4 should be applied in order to obtain the right number of presentation frames from the encoded frames.
Is this step really required in this case? All we need here is the playing time of the movie in seconds. For film with pulldown this means

Encoded_Frames / 23.976

and for NTSC video it would be

Encoded_Frames / 29.97

Since the number of encoded frames is higher by a factor of 1.25 for video compared to film, the result of the division will be exactly the same. Or is my logic all wrong?

Cheers
manolito

[Nick]

Yeah, we only need length in seconds, to the nearest second.
So there's no need for being exact to the frame. Also, I agree with manolito, there is no need to know the number of presented frames as chapters are passed to DVDAuthor in hh:mm:ss, not frames.

I just tried a quick implementation of the planned approach but it didn't work. I might get chance for a look over the weekend but if not, I'll go with the cruddy workaround for now and debug the more elegant solution when I get time.

[Sir Didymus]

@manolito...
Yes... It's evident you are right...

The point is that if you want to recover the play time (in seconds or in terms of presentation frames) you need to know in avance if pulldown should be applied or not to the encoded video...

In alternative you should know (for NTSC sources) if the framerate is 24,976 or 29,97...

I just wanted to point out that if you simply assume 29,97 for all NTSC clips, you may go off by a factor of 1.25...

[Nick]

OK, seems to work now.
http://nickspage.pwp.blueyonder.co.uk/update.zip
just the new DVDAuthor file for now. Copy to your DVDAuthor folder in the DVD2SVCD installation directory.

Also included - the FreeBASIC script file.
The changes are that it now checks before generating the xml file for DVD Author, whether movie length has been detected as zero.
If so, it runs a new subroutine called "contingency"

This checks the ecl file for start and end frames, and obtains the framerate from the d2s project file.

Movie length in seconds = (end frame - start frame) / fps
expressed as an integer.

It then checks again if movie length = 0 - this could only happen AFAIK if CCE 2.7 is used but the ecl file has been deleted, or if another unsupported encoder is used. If it is 0, it sets it to 20000 (about 5h30m) and then generates the xml.

Subject to it working for everyone else, I'll recompile the installer this week sometime and upload it.

[manolito]

Just did a quick test with a PAL Avi using CCE 2.70 and fixed chapters. Works beautifully...:)

Will do NTSC tests ASAP


OT: Kurtnoise just uploaded a new Aften Build rev531. This build does NOT work with AC3Enc.


Cheers
manolito

[manolito]

NTSC tests:

I used two NTSC XviD Avi files, one @ 29.97 fps (no pulldown) and one @ 23.976 fps (pulldown). The clips both had a length of 2min 01sec. Fixed chapters every 20 sec were selected. CCE 2.70 was my encoder.

Results:
In both cases the DVDAuthor.xml file showed the correct number of chapters up to 2min. No problems whatsoever...:)

Cheers
manolito

[manolito]

Both Kurtnoise and Wisodev just have issued new builds of Aften.

Wisodev's build 561 (VS2005) does NOT work with Nick's AC3Enc plugin, but the version from Kurtnoise DOES. And on my machine this is also the fastest version of Aften I have come across so far.

Cheers
manolito

[wisodev]

Both Kurtnoise and Wisodev just have issued new builds of Aften.

Wisodev's build 561 (VS2005) does NOT work with Nick's AC3Enc plugin, but the version from Kurtnoise DOES. And on my machine this is also the fastest version of Aften I have come across so far.

Cheers
manolito

I have switched to new build system and my new binaries have by default enabled Multi-Threading and all SIMD optimizations (MMX,SSE,SSE2,SSE3). To be sure that aften runs on older hardware you can change command-line to something like this:

aften.exe -threads 1 -nosimd mmx,sse,sse2,sse3 your_file.wav your_file.ac3
Note: you can also disable only part of optimizations by changing for example -nosimd mmx,sse,sse2,sse3 to -nosimd mmx.

[manolito]

Hi Wieslaw,

I just downloaded and tried your latest build with Nick's AC3Enc plugin, but it still does not work on my machine.

The objective of the plugin is to work with ANY CPU without modifying the command line. The plugin calls Aften with this command line:
BeSweet.exe -core( -input I:\Movies\Extracted_audio_1.wav -output I:\Movies\Encoded_audio_1.mp2 -logfile I:\Movies\Encoded_audio_1.log ) -ota( -g max ) -shibatch( --rate 48000) -bsn( -exe aften.exe -b 384 )
It uses the modified BSN.DLL by Kurtnoise to make BeSweet compatible with Aften.

My CPU is an older Intel Celeron Coppermine which supports only MMX and SSE (no SSE2 or SSE3). When I use the latest Aften build by Kurtnoise the log file correctly says "SIMD: MMX SSE, Threads: 1", and the encode works. With your latest build I get "SIMD MMX SSE SSE2 SSE3, Threads: 1", and the encoder hangs at this point.

So it looks like Kurtnoise detects the CPU capability while your build just assumes that the CPU is capable to support all optimizations, and if the CPU does not then you have to alter the command line accordingly. But I think that changing the command line depending on the CPU is not an option for Nick's plugin. The command line issued by the plugin should just work for ANY CPU.

Cheers
manolito

[manolito]

New Aften Version 0.0.8 is out.

Again Wisodev's build hangs on my machine (MMX and SSE1 only), but the Kurtnoise build detects the CPU capabilities correctly and works perfectly here.

Cheers
manolito

[manolito]

While I tested if the latest Aften 0.0.8 (Kurtnoise build) still worked correctly in 5.1 mode for a movie longer than 2 hours (it does work perfectly), I made this interesting observation:

Using the batch version of the plugin is significantly faster on my machine than using the EXE version. For a 2 and a half hour movie in 6ch AC3 to 6ch AC3 mode the EXE plugin needed 58 minutes (62 minutes for the included Aften 0.0.7), while the batch version only took 44 minutes (49 minutes with Aften 0.0.7).

The better performance of Aften 0.0.8 compared to 0.0.7 is in the exspected range (MMX + SSE1 optimization vs. no optimization), but I absolutely have no clue why using FreeBasic should slow down Aften this much.

Any ideas?

Cheers
manolito


P.S. The download links in the very first post of this thread both point to the the same file (batch version). Can you correct this?

[Nick]

Links corrected.
No idea whatsoever why the exe versions should be slower at all - for the DVDAuthor aspect I found the exe version significantly faster.

I can't say I've done time trials of really long files. I'll do some test runs when I get a minute (wednesday probably) and see if your results are repeatable here.

Thanks for the heads up anyway. I'll look into this.

[manolito]

After trying to analyze task manager information for both plugin versions it looks like memory usage is the reason for the performance difference on my machine (I only have 512 MB of RAM).

Here are the relevant numbers:

Batch version:
CPU usage Memory
BeSweet 40% 3116
Aften 50% 1304
DVD2SVCD 0% 9788


EXE version:
CPU usage Memory
BeSweet 40% 1208
Aften 50% 1064
DVD2SVCD 2% 15088
MPEG51.exe 0% 56


The interesting part is the memory usage of DVD2SVCD. On a machine with more RAM this might not make much of a difference, but on my computer it certainly does.

Cheers
manolito

[wisodev]

New Aften Version 0.0.8 is out.

Again Wisodev's build hangs on my machine (MMX and SSE1 only), but the Kurtnoise build detects the CPU capabilities correctly and works perfectly here.

Cheers
manolito

New build (http://win32builds.sourceforge.net/aften/index.html) should fix the issues you had with my binaries (download VERSION 0.0.8 UPDATED (http://win32builds.sourceforge.net/aften/index.html)).

[Nick]

OK. Finally got round to updating this.

New version (same links in original post) differs as follows:

1) Aften version updated to 0.0.8 (and not before time). I still can't get wisodev's build to integrate properly with my plugin so I've gone with Kurtnoise's build.

2) Bug in the installer fixed. Deinstallation of older versions did not clean up all the old files. Now it does.

3) Delay in rofile.bat shortened. This aspect of the plugin write-protects the converted audio file in 5.1 mode for a few seconds when video encoding begins, otherwise DVD2SVCD inexplicably deletes it. The arbitrary time I chose of 20 seconds interferes with the HCEnc plugin of manolito's. Delay now 3 seconds which seems long enough to stop deletion but allow the HC plugin to function correctly.

[bionic]

Thanks Nick, much appreciated :)

[manolito]

Thank you Nick,

just one question: The new EXE build still has the older AC3_DVDAuthor.exe in it, not the update from this post http://forum.doom9.org/showthread.php?p=1024764#post1024764
Oversight or did you find any issues with the updated version?

Cheers
manolito

[Nick]

Oversight!

I haven't looked at this for a while and, thinking the last build would be the last for at least a while, I left the project files in something of organised choas. When I returned to it some months later, I had forgotten the organisation and was just left with the chaos!

It should now be fixed.

[Nick]

Slight update.
A typo in the AC3Enc8 FreeBASIC script (missing open-bracket, line 23) led to failure with exe's and frame selection.

Fixed.

Link as per opening post in the thread.

[bionic]

Thanks man :)

[ChickenMan]

Nice :)

[rip-in-peace]

Hi All

Been a "silent" visitor to this forum for quite a while and have been using DVD2SVCD for some time. (a killer app for me)

Have read through the posts on this thread but I'm a little confused... thread states "using this app for DVD output with ac3 audio" - that's simple enough with an extra prog. Whats the input format you are having trouble with?
V1.1.3.B2 rocks for me.

RIP

[manolito]

Hi RIP,
since Nick seems to be unavailable, I will try my best to answer your questions. :)
thread states "using this app for DVD output with ac3 audio" - that's simple enough with an extra prog
I´m not sure that I understand what you are really asking.

Without Nick´s plugin DVD2SVCD cannot create DVD output with AC3 audio unless your source already has AC3 audio and you tick "Do not convert audio". If your source audio is PCM or MP3 then DVD2SVCD can only convert it to MPEG (MP2).

This is acceptable for a PAL DVD, but for NTSC the specs say that a DVD with only MPEG audio is not DVD compliant, you need at least one AC3 track. Well, most NTSC standalone players will play a DVD with just MPEG audio, but it never hurts to comply to the standards.


Cheers
manolito

[ChickenMan]

I've just upgraded to Windows 7 (32bit) and having trouble to get AC3Enc8.exe to run in DVD2SVCD. I am trying to convert an avi with mp3 audio, same one converted fine in XP. It extracts okay, converts to WAV okay, but as soon as Ac3enc8 starts, it instantly shuts down and no Encoded_audio_1.mp2 is ever produced, not even a 0kb length file. I have changed compatibility to XP SP3 for all exe files in my BeSweet folder, same problem. I have tried many avis (xvid with mp3) and all experience the same problem.

If the avi has ac3 audio, ac3enc8 stays fired up and an Encoded_audio_1.ac3 is produced as per normal.

I can run Aften.exe manually with no problem. BeSweet runs manually also no probs.

Anyone else seen or have this problem, or better still a solution ? Thanks.

Edit:
This is my Encoded_audio_1.log file --

BeSweet v1.5b31 by DSPguru.
--------------------------
Using Shibatch.dll v0.25 by Naoki Shibata & DSPguru (shibatch.sourceforge.net).
Using bsn.dll v0.24 by DPeshev,Richard,E-Male,DSPguru (DSPguru.Doom9.org).

Logging start : 01/20/10 , 09:20:33.

BeSweet.exe -core( -input K:\TEMP02\Encoded_audio_1.mp2.wav -output K:\TEMP02\Encoded_audio_1.mp2 -logfile K:\TEMP02\Encoded_audio_1.log ) -ota( -g max ) -shibatch( --rate 48000) -bsn( -exe aften.exe -b 224 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : K:\TEMP02\Encoded_audio_1.mp2.wav
[00:00:00:000] | Output: K:\TEMP02\Encoded_audio_1.mp2
[00:00:00:000] | Floating-Point Process: No
Error 84: error configuring bsn!
Quiting...
[00:00:00:000] Conversion Completed !

Logging ends : 01/20/10 , 09:20:33.

[ChickenMan]

I installed AC3EncSetup.exe (downed from the first post of this thread) and it installed AC3Enc7.bat ( and deleted my AC3Enc8.exe :( ). Only run one trial avi through but it seams to work just fine, just a lot lot slower than what I'm used to with AC3Enc8.bat. But hey, if it continues to work, speed is not a real issues.

[manolito]

Hi ChickenMan,

looks like FreeBasic has an issue with Win7 :confused:

First thing I suspected after reading your log was BSN.DLL and Win7 might not get along...
Error 84: error configuring bsn!
But this cannot be true if the AC3Enc7 (bat) package works, because it uses the same version of bsn.dll as the AC3Enc8 (exe) package.

Otherwise (except for speed) the two versions work identically. We should ask Nick if he already has Win7 installed, and if he can reproduce the error. Another reason for me to stick with XP for the time being...:p


Cheers
manolito

[Nick]

Managed to miss the 2010 updates to this, so sorry for the late response!

I don't have Windows 7 installed - indeed I haven't had any version of Windows installed for some 2 years now! Which I guess means this one is a dead project.
I have uploaded AC3Enc8.bat to my webspace so you can update manually:
http://nickspage.pwp.blueyonder.co.uk/AC3Enc8bat.zip
Just extract to the BeSweet folder and set the path in the BeSweet tab of DVD2SVCD to use it.

The installer was made using Nullsoft Scriptable Install System, which doesn't seem to work from Linux. I can provide the script and the files required to build an installer for the batch files if anyone is so mindful. Indeed I will happily make all the files available to anyone who wishes to seize the reins on this project.

Can't find anything on the FreeBASIC forums to explain any issues with Windows 7 and certainly FreeBASIC itself has not seen an update since 2008. So there wouldn't be anything I could do about it anyway.

[ChickenMan]

Good to see you again Nick :) I have been using AC3Enc7.bat very successfully since my last post but will give AC3Enc8.bat a go.

Though the one problem any version of AC3Enc has been unable to do, is convert a mono mp3 (within an AVI) through to a mono or stereo AC3. The result is always twice the original length and drawn out. I've lived with it now for so long, I suppose I can continue to do so.

[Nick]

Hmm. Might get chance to have a look at that sometime. Otherwise I guess use something like Avidemux to convert the audio to stereo first.

BeSweet runs under Linux using Wine, so if you were to upload a short extracted mp3 file to somewhere line Mediafire.com, I could take a look and see if there is an easy fix. Sadly DVD2SVCD doesn't run so I can't really do that much testing. Since Avisynth, HC, Batchmux and the 0.15R revision of Muxman all run under Wine and Aften is native to Linux anyway, I just have a simple shell script to automate my DVD encodes.

Remind me what happens with a mono mp3 file - does MadPlay run to convert it to a wav file? If so is the wav file correct? And can you convert to mono mp2 if you don't use the plugin?

[ChickenMan]

Yes, MADPLAY converts the extracted mono mpa file to a mono WAV file just fine. I then manually load the mono WAV file into Goldwave, convert to Stereo, normalize, sample to 48kHz if needed and save back out as a WAV. I then use WAV to AC3 Encoder v0.9 to convert to ac3 (it uses Aften for the conversion). Then rename the out put to Encoded_audio_1.mp2. I do this while dvd2svcd is running and encoding the video and when thats done and authoring starts, it sees the correct named audio file and authors to a dvd and all is well.
So the problem lies with the BeSweet stage.

[Nick]

OK. So the next question is whether it works without the plugin.
If BeSweet creates a duff mp2 file when the plugin isn't used, then it will always produce a duff ac3 file when it is. All the plugin does is parse the BeSweet commandline and rewrite it to use Aften instead of 2Lame as the encoder.

If on the other hand, mp2 audio works fine then there it is an issue directly connected to the plugin and therefore can be resolved.

[ChickenMan]

Okay, just did a couple of test runs. AVI is an xvid 1hr 40min long with mono mp3 (87bit/s and 48khz). D2S with audio set to use BeSweet.exe (the one bundelled with D2S) it extracts and MAdplay converts to mono WAV. Then BeSweet converts to a mp2 file STEREO and 1hr 40min long, so all good, just mp2 not ac3. Changed Audio to use AC3Enc8.bat, ran same file, and now get an ac3 file, stereo but 3hr 20min long and speech sound ssttrreettcchheed oouutt. Thats exactly twice the length of the original.

[manolito]

Hi Nick and Chickenman,

good to see you guys again...:)

For sources with mono audio DVD2SCVD always threw up IMO. This has nothing to do with the AC3Enc Plugin. Here is Nick's own quote from the DVD2SVCD stickies:
If your AVI has mono audio, it will not convert properly in DVD2SVCD - the output will be double speed and sound very high pitched. If this is the case (VDubMod File menu > File information will tell you), then go into Streams menu > Streams list and right-click on the audio stream. Select "Full Processing mode" from the menu that appears. Now right click again and choose Conversion. In the window that opens, select Stereo under the "Channels" heading and click OK. Save the AVI as instructed above and it should now work.

I also just checked the differences between AC3Enc7.bat and AC3Enc8.bat. Only 2 significant changes:

In AC3Enc7.bat BeSweet is called with the "Start /w /min" parameter, while AC3Enc8.bat calls BeSweet directly. On my Win XP SP3 system this does not make a difference.

For 5.1 output AC3Enc8.bat now saves the parameters to the file "fiveone.txt" instead of "fiveone.ini". This seems to be a bug since MPEG51(4).bat expects "fiveone.ini" as its input.


Cheers
manolito

[Nick]

???

My copy of MPEG51(4).bat says fiveone.txt

I think I need to sort out my files.
Obviously manual editing of either/or will fix that bug in the short term.

[ChickenMan]

Hi Manolito, good to see you to :)


In AC3Enc7.bat BeSweet is called with the "Start /w /min" parameter, while AC3Enc8.bat calls BeSweet directly. On my Win XP SP3 system this does not make a difference.
Arr... its the other way around

For sources with mono audio DVD2SCVD always threw up IMO.
Its never been a problem when converting to mp2 as per original D2S and just using the BeSweet.exe, its only since using the ac3 pluggin (of all versions) that the conversion of mono audio takes a dive. I ran a small test yesterday and confirmed mono converts to stereo mp2 correctly using BeSweet.exe for audio conversion.