VIDEO_TS folder undersized ?

[iparout]

Hi.

I just finished backing up the T2 movie and after muxing with Scenarist and putting all files in a VIDEO_TS folder, to my surprise I saw that the VIDEO_TS folder is only 3.65 GB.

I encoded the movie at 2535 kbps using 5 passes and the extras at 2000 kbps using 7 passes. The last lines of the DIF4U log file are those :

(01:15:42) Finished copying unused VTSes
(01:15:43) Extras Assets= 45725952 bytes, DVDR Size= 4700000000
(01:15:44) Main VTS Assets= 2072020742, Chosen DVDR Size= 4700000000, Video_TS Directory= 359327744 bytes
(01:15:45) --------------------------------------------------------------------------------
(01:15:45) | Create CCEData.txt and Calculate Bitrates |
(01:15:45) --------------------------------------------------------------------------------
(01:15:45) Final Bitrate Calculations...
(01:15:45) (Doesn't work with HDD Demux mode, all other modes supported now!)
(01:15:45) CCE Recommended values: MAIN: AvgBitrate= 2535
(01:15:45) CCE Recommended values: EXTRA: AvgBitrate= 2000
(01:15:45) (See CCEData.txt for detailed information.)
(01:15:50) -
(01:15:50) Creating REJIGdata.txt file for use with Rejig 0.4b+

As you can see, the predicted size for the VIDEO_TS directory was around 3.6 GB (almost exactly the size it turned out to be after processing the movie), however I do not understand why only 3.6 GB should be used from the almost 4.37 GB the DVD+R can handle. It's not like I couldn't use the bandwith...

BTW, I checked the extras with Bitrate Viewer and found them to have an average bitrate of around 1500 kbps (!), although I aimed for 2000 kbps at 7 passes. I would have expected for much more accuracy...

Any comments that could enlighten me on this matter (especially the undersized VIDEO_TS folder), would be more than welcome...

Thanks in advance.

[D3s7]

which "VIDEO_TS" folder are you looking at? the one in 0\VIDEO_TS?

if so, then you haven't finished the steps.. if you see the "Extra" assets would make up most of the difference

Usually this is the main cause for undersizing is not all the needed assets are in the right folder

[iparout]

Originally posted by D3s7
which "VIDEO_TS" folder are you looking at? the one in 0\VIDEO_TS?

if so, then you haven't finished the steps.. if you see the "Extra" assets would make up most of the difference

Usually this is the main cause for undersizing is not all the needed assets are in the right folder

No, I copied all the .VOB files that scenarist generated (they were in the \0\VIDEO_TS folder), in the VIDEO_TS folder that DIF4U had created... (the guide says to copy ALL files into a new directory, but I did it the way I described which, if I'm not mistaken, is the same...) As far as I have understood, this folder (which was initially created by DIF4U) would now be the VIDEO_TS folder that should be burnt on the DVD+R, and it's only 3.65 GB.

I can't see why...

As far as I can understand, the whole process of re-encoding and re-authoring the DVD went just fine. I mean, the target filesize for the VIDEO_TS folder was 3.6 GB (see DIF4U log) and it turned out to be 3.6 GB indeed... What I don't understand is why DIF4U targeted for a 3.6 GB VIDEO_TS folder, whereas the DVD+R is around 4.37...

[D3s7]

well if you copied ALL the vob files then you overwrote the original files which is where your problem is.

For example if you demuxed VTS01 and VTS03, the original VTS02 files will be in the VIDEO_TS folder. If you copy ALL the vob's from the authored directory, you would overwrite the correct VTS02 with the dummy one from the scenarist directory.

Here is the rule of thumb - and I'd recommend you read Eyes`only's post on "A Better way to do the IFOUPdate Step" which you can find using the search routine - copy the files from the 0\VIDEO_TS directory to the VIDEO_TS directory. When your prompted to overwrite files, say NO!

(Also make sure you ONLY ifoupdate the assets you demuxed)

[Chubmeister]

Did you have 'uncheck duplicate pgcs' in DOITF4U?

It would encode those files twice or more depending on how many times duplicated. I've done it myself without realising, ie. not knowingly changed this setting within DOITF4U but I've always noticed in BatchCCEWs that the bitrate looked too low and corrected it.

But, I wonder if scenaid/scenarist knows to just use the one file when its compiling, thus creating a much smaller DVD.

Just a thought.

[iparout]

Originally posted by D3s7
well if you copied ALL the vob files then you overwrote the original files which is where your problem is.

For example if you demuxed VTS01 and VTS03, the original VTS02 files will be in the VIDEO_TS folder. If you copy ALL the vob's from the authored directory, you would overwrite the correct VTS02 with the dummy one from the scenarist directory.

Here is the rule of thumb - and I'd recommend you read Eyes`only's post on "A Better way to do the IFOUPdate Step" which you can find using the search routine - copy the files from the 0\VIDEO_TS directory to the VIDEO_TS directory. When your prompted to overwrite files, say NO!

(Also make sure you ONLY ifoupdate the assets you demuxed)

I see what you're saying, however I didn't overwrite any of the files during the process I described (if I was to overwrite any files, Explorer would have asked me if I am sure, which didn't happen).

The movie has 4 VTS streams (VTS01, VTS02, VTS03, VTS04), of which only VTS01 and VTS02 where demuxed with DIF4U. The rest (VTS03 and VTS04) where just copied to the DIF4U VIDEO_TS folder.

When running Scenarist, the only VOBs that were exported (muxed) and afterwards copied by me into the DIF4U VIDEO_TS folder, were VTS_01_1, VTS_01_2, VTS_01_3 and VTS_02_1. The VTS_03_1.vob and VTS_04_1.vob placed in the DIF4U VIDEO_TS folders where the ones that DIF4U copied at the very beginning of the backup process (they weren't overwriten whatsoever), and I am completely sure about that cause I can tell by reading the "Dates Modified".

And as I already said, there was no "Would you like to overwrite XXXX ?" dialogue box when I copied the files...

So I guess the problem is somwhere else.

[iparout]

Originally posted by Chubmeister
Did you have 'uncheck duplicate pgcs' in DOITF4U?

It would encode those files twice or more depending on how many times duplicated. I've done it myself without realising, ie. not knowingly changed this setting within DOITF4U but I've always noticed in BatchCCEWs that the bitrate looked too low and corrected it.

But, I wonder if scenaid/scenarist knows to just use the one file when its compiling, thus creating a much smaller DVD.

Just a thought.

Well, I can see that the "Uncheck Autodetected Duplicate PGCs in reverse order" option under Pre-Processing is not enabled. The guide SAID to enable it, however the screenshot there had it disabled and thus I didn't enable it. My bad... Do you think that's the reason why I got undersized problems ?

[D3s7]

Hmm.. well then I'm not sure :)

however after re-reading your log file and checking it to mine you are misreading it

(01:15:43) Extras Assets= 45725952 bytes, DVDR Size= 4700000000
this line is telling you how many bytes is in the extra demuxed assets. In your case, if VTS01 is the main movie, this is what VTS02 is roughly

(01:15:44) Main VTS Assets= b, Chosen DVDR Size= 4700000000, Video_TS Directory= 359327744 bytes

THe "Main VTS Assets" is the VTS set that was flagged as "MAIN" in DoItFact4u, the VIDEO_TS dir is the total off all Non demuxed vts sets (3 and 4 in your case)

However, the "Main VTS" I don't believe is bytes though.. "maybe seconds, maybe milliseconds"

The only other thing I could suggest checking is if you have all your menu files in the directory... (these would be all teh _0.VOB) files

[iparout]

Originally posted by D3s7
Hmm.. well then I'm not sure :)

however after re-reading your log file and checking it to mine you are misreading it

(01:15:43) Extras Assets= 45725952 bytes, DVDR Size= 4700000000
this line is telling you how many bytes is in the extra demuxed assets. In your case, if VTS01 is the main movie, this is what VTS02 is roughly

(01:15:44) Main VTS Assets= b, Chosen DVDR Size= 4700000000, Video_TS Directory= 359327744 bytes

THe "Main VTS Assets" is the VTS set that was flagged as "MAIN" in DoItFact4u, the VIDEO_TS dir is the total off all Non demuxed vts sets (3 and 4 in your case)

However, the "Main VTS" I don't believe is bytes though.. "maybe seconds, maybe milliseconds"

The only other thing I could suggest checking is if you have all your menu files in the directory... (these would be all teh _0.VOB) files

Well, I have all the menu files in the directory, that's for sure... However I don't know if you read the post above your last one. I had the Uncheck Duplicate PGCs disabled in DIF4U. Maybe that's the reason for my problem ? I don't know...

[D3s7]

Originally posted by iparout
Well, I can see that the "Uncheck Autodetected Duplicate PGCs in reverse order" option under Pre-Processing is not enabled. The guide SAID to enable it, however the screenshot there had it disabled and thus I didn't enable it. My bad... Do you think that's the reason why I got undersized problems ?

That's possible (good thought chub)
Try enabling that option and see if any of the PGC's are unchecked by DoItFast4u. ScenAid would attempt to label both assets the same (as they really are) and as a result, Scenarist would rename/not use the second asset..

For example if both PGC1 and 2 use VOBID 3 CellID 2 then you'd find 2 VTS_01_V3_C2 (other would probably be VTS_01_V3_C2-1 or -2 or _1..) - The layout would use VTS_01_V3_C2 and ignore the other.. resulting in final asset being undersized

[iparout]

Originally posted by D3s7
That's possible (good thought chub)
Try enabling that option and see if any of the PGC's are unchecked by DoItFast4u. ScenAid would attempt to label both assets the same (as they really are) and as a result, Scenarist would rename/not use the second asset..

For example if both PGC1 and 2 use VOBID 3 CellID 2 then you'd find 2 VTS_01_V3_C2 (other would probably be VTS_01_V3_C2-1 or -2 or _1..) - The layout would use VTS_01_V3_C2 and ignore the other.. resulting in final asset being undersized

I enebled the feature and run DIF4U again, however no PGCs were unchecked and DIF4U says : No Duplicate VobIDs found. So I guess that's not the problem.

And, well, the Main VTS may be sec or ms, but the Video_TS directory size is definately bytes and as you can see the targeted size of VIDEO_TS is 3.6 GB instead of 4.37... I can't understand why DIF4U targets to create such a small VIDEO_TS folder. I think that the problem is actually right there.

[D3s7]

that's NOT a target size.. that's what your ORIGINAL video_ts folder should be - take that value and / 1024 / 1024 and you'll get 360 not 3600 (bytes / kbytes / megabytes)

Other then that I really am not sure... perhaps you can email/talk with Eyes`only about it.. he might have a better idea

[iparout]

Originally posted by D3s7
that's NOT a target size.. that's what your ORIGINAL video_ts folder should be - take that value and / 1024 / 1024 and you'll get 360 not 3600 (bytes / kbytes / megabytes)

Other then that I really am not sure... perhaps you can email/talk with Eyes`only about it.. he might have a better idea

Thank you very much for helping me out...

I am gonna bother eyes'only for this matter and hopefully he'll find a solution/explanation...

BTW, I run all .mpv files through Bitrate Viewer to find out their average bitrate and those are the results :

VTS01_P01.mpv (Main Movie) : Average bitrate was 2010 kbps instead of the calculated 2535 kbps.

And generally all the extras .mpv files (3 .mpv files in total), had an average bitrate of 1500 kbps rather than 2000 kbps which I requested...

If that's the truth, maybe the undersize problem was because the streams were encoded with CCE at a lower bitrate than the one siggested by DIF4U.

I don't know if Bitrate Viewer is accurate though, cause during the encoding process, I had a look to CCE every now and then and the average bitrate showed while encoding the movie was indeed around 2500 bps and not 2010 kbps as Bitrate Viewer suggests. Unfortunately though, I didn't have the time to look at CCE at the final staged of the encoding to see if the average bitrate had dropped...

[iparout]

I think I found the problem ! The movie has a DTS audio track which is 700 MB is size (exactly as the undersize). Scenaid said that this file would be imported as a PlaceHolder in Scenarist and I was supposed to replace it with data. Well, I did so by right clicking the PlaceHolder and converting it to data (PlaceHolder -> Data), however it looks like this track has not been properly muxed into the final vobs by Scenarist... (I played the movie and after the DTS track plays for 2-3 seconds at the beginning of the film, it then mutes for the remaining movie.)

Does anyone have any idea on why this happened ? I'm gonna compile the movie again wuth Scenarist, so does anyone know how to avoid this problem ?

Thanks in advance.

P.S. : I realised I didn't actually have a DTS decoder on my PC so I downloaded the Audio Pack for PowerDVD 5 in order for it to support DTS audio. However, during the backing-up process of the DVD (including the Scenarist muxing), there was no DTS decoder on the PC. I don;t know if that matters though.

[D3s7]

what version of scenaid are you using?

the new builds should not import the DTS audio as a placeholder. I'm suprised that it even muxed though... normally Scenarist won't mux a project if there is a placeholder

the decoder doesn't matter though

[iparout]

Originally posted by D3s7
what version of scenaid are you using?

the new builds should not import the DTS audio as a placeholder. I'm suprised that it even muxed though... normally Scenarist won't mux a project if there is a placeholder

the decoder doesn't matter though

I'm using 0.9.0.5. Do you think that installing one of the newer versions would fix the problem ? Cause I DID replace the placeholder with data in Scenarist by right-clicking it, as Scenaid 0.9.0.5 said... Do you believe that the DTS stream is not muxed at all ? It does play for the first 2-3 seconds of the movie. And I honestly need to know for sure that this is the problem before re-compiling, cause it will be a pain to wait half an hour for Scenarist to finish just to find out that this was not the problem... ;-)

1) If I use one of the newer versions of Scenaid, is it recommended to enable the "fix delay" options under Audio Options or not ?

2) If I use the newest Scenaid versions to fix the problem, I would have to compile again with Scenarist. So there might be a problem with the original VIDEO_TS folder that DIF4U created. This folder (apart from the files copied by DIF4U in the beginning) now also contains the VOBs created by Scenarist (that's no problem, I'll delete those), but also the updated versions of VTS_01_0.bup, VTS_01_0.ifo, VTS_02_0.bup and VTS_02_0.ifo which were created with IfoUpdate. What should I do with those files ? How do I re-convert them to their initial status (prior to being edited by IfoUpdate).

I've kept backups of those files during the IfoUpdate, however the backups are only the .ifo files and not the .bup files (I don't know why IfoUpdate didn't backup the .bup files before editing them).

Should I replace the edited ifos with the backups and leave the bup files as it is, or should I just overwrite those ifos and bups with the files that are on the original DVD ?

[stanjr]

I don't know if you have overcome your problem with this DVD yet, but I have had this problem with three different DVDs myself so far. All three of them were concert DVDs (The Cure Trilogy discs 1 and 2 and New Order 511). I don't remember if The Cure Trilogy discs had DTS streams on them or not (though, they did have Dolby Digital 5.1); however New Order 511 does have a a DTS stream (although I am not including it in the re-authored backup). All of these demuxes I originally did by PGC and DoItFast4U calculated an average bitrate that ended up being too low for an efficient use of the DVD size. I didn't think to try demuxing by VOBID until now to see if I would get a different bitrate calculation. I am working on New Order 511 right now and did get a higher bitrate when I demuxed by VOBID (I also manually checked every PGC that DoItFast4U unchecked). I am re-encoding now, so we'll see how it turns out.

[D3s7]

The problem you both may be having is the duplicate PGC ONLY works if ALL the vobids / cellids are used in another PGC. If only 1 or some are, then no it can't be done that way, it has to be done by VOBID demux. The other problem sometimes is if the video is reused but the audio isn't.. but then you usually lose the audio.

If you get a higher bitrate by doing a vobid demux, that's probably the case

[iparout]

Originally posted by D3s7
The problem you both may be having is the duplicate PGC ONLY works if ALL the vobids / cellids are used in another PGC. If only 1 or some are, then no it can't be done that way, it has to be done by VOBID demux. The other problem sometimes is if the video is reused but the audio isn't.. but then you usually lose the audio.

If you get a higher bitrate by doing a vobid demux, that's probably the case

Well, keep in mind that I can't hear the DTS audio in the output DVD+R, so maybe this audio stream isn't muxed. I'll try the latest Scenaid version as you suggested to see if the DTS stream will be muxed correctly.

If I still get an undersized output, I'll try to demux by VonID, as you suggest. In that case, are there any other settings in DIF4U that I should change ? (I have the settings described in the newest big3 method)

And last but not least, how is it possible to know in advance when to demux by VobID and when not ? (Without of course doing all the job and seeing the undersized output)

[Eyes`Only]

@iparout: When you mux after replacing the placeholder, are the .vobs a different size than before?

@stanjr: Just FYI... there's no need to check the unchecked pgcs for vobid demux, the nature of DVD Decrypter makes it to where a vobid demux has to include all PGCs, and though I am planning to code something to remove the unchecked PGCs's vobids, I haven't done so yet. So all PGCs are automatically demux for any vobid demux. Just a helpful hint to save you some time.

It's not altogether that weird that DTS seems to be causing this issue... unfortunately muxing DTS seems to result in a much larger filesize ratio and though I've been somewhat successful in my attempts to determine this ratio, it appears I'm not 100% successful :(

[iparout]

Well, I'm happy to announce that the problem is sorted. It looks like the DTS stream was not muxed into the movie, because of using the ols Scenaid (0.9.0.5). After installing the newest one (0.9.0.24), the DTS stream was successfully muxed and the output VIDEO_TS folder was 4.36 GB.

Thanks everyone for providing me with help and recommendations. ;)

[Eyes`Only]

*whew*

[D3s7]

ditto

[stanjr]

Well, I just completed my project via a VOBID demux, and I am still only at 3.6 GB. Very strange.

I did not pick the DTS stream to be included in the re-authored backup; however, with VOBID demux, it is demuxed anyway, right?, so maybe DoItFast4U's bitrate calculations are still including it for some reason?

If so, how could I get around that?

Thanks for any help!

P.S. I just noticed that the only VTS that has DTS is VTS05, and that in the VTS05 subfolder, there is a WAV file named "VTS__05_V001-A0-1536K-[0ms]-ch_NotSpecified.WAV" This is probably the demuxed DTS, converted to WAV. It was a little over 1 GB in size and, if added to my project outcome of 3.6 GB, would get me to 4.7 gig. It really does seem to be that DoItFast4U included a not-wanted audio stream in its bitrate calculations. Are maybe a couple of work-arounds to just re-encode the video with a bitrate that is what DoItFast4U originally calculated plus 1536 (what seems to be the bitrate specificed for the not-wanted WAV file) or in DVD Decrypter settings for Stream Processing, not have convert-PCM-to-WAV checked for when demuxing and start over?

[D3s7]

no, audio / subs are still subject to what you select during a VOBID demux. The only thing that's "auto" demuxed is all the PGC's (as that's where the vobid's are found/built)

So if you deselected / unchecked it in the Doitfast4u interface, it should not have been included in the calcs

[stanjr]

P.S. I just noticed that the only VTS that has DTS is VTS05, and that in the VTS05 subfolder, there is a WAV file named "VTS__05_V001-A0-1536K-[0ms]-ch_NotSpecified.WAV" This is probably the demuxed DTS, converted to WAV. It was a little over 1 GB in size and, if added to my project outcome of 3.6 GB, would get me to 4.7 gig. It really does seem to be that DoItFast4U included a not-wanted audio stream in its bitrate calculations. Are maybe a couple of work-arounds to just re-encode the video with a bitrate that is what DoItFast4U originally calculated plus 1536 (what seems to be the bitrate specificed for the not-wanted WAV file) or in DVD Decrypter settings for Stream Processing, not have convert-PCM-to-WAV checked for when demuxing and start over?

So I just finished re-encoding with a bitrate that was what DoItFast4U originally calculated plus 1536 and ended up with an ISO that was WAY closer to the correct DVD size, though a little bit over. I am re-encoding a second time, working from the backup, which is now sans DTS. The bitrate that DoItFast4U calculated this time around seems believable (only 244 kbps different than the approach I took to get the DVD close to correct size).

It seems that DoItFast4U may have an issue calculating bitrate when DTS is involved.

Any thoughts?

[D3s7]

you are correct... Doitfast4u needs to know the # of channels to accuratly calculate the overhead this asset would use... that's why it wasn't included ( now that I notice that it's missing in the file name)

I would do this... try manually demuxing the assets in dvddecypter. See if that file name includes channels. If not, contact light_uk and report a bug/problem. If it does, contact Eyes`Only and report the bug to him :)

[stanjr]

P.S. I just noticed that the only VTS that has DTS is VTS05, and that in the VTS05 subfolder, there is a WAV file named "VTS__05_V001-A0-1536K-[0ms]-ch_NotSpecified.WAV" This is probably the demuxed DTS, converted to WAV. It was a little over 1 GB in size and, if added to my project outcome of 3.6 GB, would get me to 4.7 gig. It really does seem to be that DoItFast4U included a not-wanted audio stream in its bitrate calculations. Are maybe a couple of work-arounds to just re-encode the video with a bitrate that is what DoItFast4U originally calculated plus 1536 (what seems to be the bitrate specificed for the not-wanted WAV file) or in DVD Decrypter settings for Stream Processing, not have convert-PCM-to-WAV checked for when demuxing and start over?

For comparison, I just tried the second "work-around" : unchecking convert-PCM-to-WAV in Stream Processing settings in DVD Decrypter, and then letting DoItFast4U demux. I got the exact same bitrate for all assets that working from the backup gave me!

I guess convert-PCM-to-WAV affects DoItFast4U's bitrate calculations if checked, due to the DTS PCM stream being converted to a WAV stream. I think for all future demuxes, I will make sure that I DO NOT have that checked in DVD Decrypter!

....And now that I looked at the PCM filename "VTS_05_VOBID_001_1 - 0xA0 - Audio - PCM - 2ch - 48kHz - 16bit - DELAY 0ms.PCM," it seems that the number of channels IS specified for a PCM stream.

I wonder why a WAV file demuxed wouldn't have the number of channels specified?

[D3s7]

Good.. i'm glad you figured it out. I would point this out to Eyes.. he may know more why. It sounds like either DVDDecypter or DoItFast4u has problem with that option and the way it names it's files... (I'm leaning more toward DVDDecypter)

Just an FYI too:

DTS <> PCM or WAV.. those are 2 totally different items. That and the fact that the channel assignment is A0 is pointing toward it being a WAV file not a DTS. (AC3 = 80-87, DTS=88-94, PCM=95-A1 - i believe.. maybe off 1 or 2)

The PCM-WAV actually just generically changes the header of the file. PCM audio IS WAV audio with a slightly different file header. Many players (although fewer anymore) can't handle PCM audio, only WAV. Plus WAV can be easily compressed to AC3 which was primarily why the option was there.

[stanjr]

This whole time I was assuming that it was the DTS stream messing with things, but it was the Linear PCM stream on channel 0xA0. There are three channels on one of the VTS's per the IFO:

Linear PCM 2ch 48Kbps 16bps 0xA0
DTS 5ch 48Kbps DRC 0x89
Dolby AC-3 6ch 48Kbps DRC 0x82

For some reason WAVs aren't named with the channel number via DVD Decrypter. I have PMed Lightning_UK concerning this.

[LIGHTNING UK!]

Hmmm no problem my end.

Just ripped in IFO mode, File mode (By File splitting) and File mode (By VOB ID splitting).

Each time the file correctly had the channels info appended to the name.

Examples:
VTS_02_1 - 0xA0 - Audio - PCM - 2ch - 48kHz - 16bit - DELAY -66ms.WAV
VTS_02_VOBID_001_1 - 0xA0 - Audio - PCM - 2ch - 48kHz - 16bit - DELAY -284ms.WAV

You either get all the info or you get none. Channel info would never be missed off on its own.

[stanjr]

Could it be that this particular WAV didn't have a correct header, assuming that Decrypter names according to header information? But why would the PCM version be named correctly?

[LIGHTNING UK!]

All that conversion does is replace the extension with WAV. There is no difference at all otherwise - so far as names are concerned.

Unless its a little something I've fixed since 3.2.2.0, there shouldnt be a problem. (EDIT: tested 3.2.2.0 now, works fine too)

Why dont you post up the names of the files that are being created when you do it.

[stanjr]

They were:

VTS_05_VOBID_001_1 - 0xA0 - Audio - PCM - 2ch - 48kHz - 16bit - DELAY 0ms.PCM

VTS__05_V001-A0-1536K-[0ms]-ch_NotSpecified.WAV

That was with DoItFast4U calling Decrypter to demux. I didn't try manually, and unfortunately, I won't be able to either 'cause I already deleted the original ISO (disc is at home, I'm at work).

[D3s7]

stan: what version of doitfast4u??

[LIGHTNING UK!]

Well if my program made a PCM, where did the WAV come from?

The PCM appears correct, wouldn't you say?

You'd only get a PCM or a WAV from my program, not both.

So maybe it's something in the ver of dif4u you're using?

[stanjr]

@D3s7: DoItFast4U v1.4.7

@LIGHTNING UK!: DoItFast4U didn't make both of them during the same demux. The PCM was made during a demux when Decrypter's convert-PCM-to-WAV setting was NOT checked. The WAV was made during a demux when Decrypter's convert-PCM-to-WAV WAS checked. Settings in DoItFast4U were the same during both demuxes.

[stanjr]

I don't have anything else, but I still have the DoItFast4U log file for the demux I did where I had convert-PCM-to-WAV checked in Decrypter.

An interesting part is shown below:

----------------------------------------------------------------------
Rename AC3Files
----------------------------------------------------------------------
AC3 File to rename= VTS_05_VOBID_001_1 - 0x82 - Audio - AC3 - 6ch - 48kHz - DELAY 0ms.AC3
Rename to= VTS__05_V001-82-448K-[0ms]-ch6.AC3
Renaming...
----------------------------------------------------------------------
Rename WAV Files
----------------------------------------------------------------------
vobloc= 001
hexloc= A0
Filename Without Delay= VTS__05_V001-A0*.WAV
numtostring= 1536
delloc= 0
ddloc= _
language= NotSpecified
Rename to= VTS__05_V001-A0-1536K-[0ms]-ch_NotSpecified.WAV
Renaming...
----------------------------------------------------------------------

If any more information is wanted, please let me know.

[LIGHTNING UK!]

Assuming you're now at home, and have access to the disc again, try manually demuxing that audio stream and see what the real names are (again) for PCM and WAV versions.

Check and see if the program ever gets the right name for a WAV. i.e. on another VOB ID or something.

Cheers.

[Eyes`Only]

that feature was not even available when 1.4.7 was put out for beta testing, so no, DoItFast4U will not get .wavs correct. But why would you convert anyway when PCM will work and is the same?

[stanjr]

Okay, finally got back to this....

When demuxed manually, the WAV or the PCM file has the correct
name. It seems that when demuxed automatically, only the PCM
has the correct name.

What also seems to be happening is that when PCM is NOT
converted to WAV by Decrypter (v3.2.2.0), DoItFast4U (v.1.4.7)
sees a correctly named PCM file but does not include it in its
bitrate calculations, ScenAid (v.25) does not include it in its
script, and Scenarist (v3.0) does not import it (nor will it
when I try to do it manually). When PCM IS converted to WAV by
Decrypter, DoItFast4U sees an incorrectly named WAV file but
DOES include it in its bitrate calculations, ScenAid does not
include it in its script, and Scenarist does not import it (but
will when I do it manually).

It seems that so far (3 or 4 discs), when I deal with a disc
that contains PCM audio, and I want to keep it, I have to make
sure Decrypter is converting PCM to WAV, then import it manually
at the Scenarist step. If I don't want to keep it, I make sure
Decrypter is not converting PCM to WAV, so that DoItFast4U does
not include it in its bitrate calculations.

[Eyes`Only]

Sorry, I incorrectly stated something. Before the new builds, DVDDec only did .wav files, leaving a .pcm was not an option that I can remember. I looked at my source and I see that I'm only checking for .wav files in 1.4.7. Somehow I'm getting the filename slightly wrong, I'll put it on the to-do list (hopefully my site will be back up soon so I can rls it!)

[LIGHTNING UK!]

Twas round the other way Eyes buddy old pal.

It used to only create PCM files, then I added the option to have it convert PCM to WAV - this option was 'checked' by default.

It's on the 'stream processing' tab in the settings.

Anyway, so long as you're aware of whatever incompatibility exists, I know you'll fix it :)

BTW, I fixed another problem of ours the other day after trahald told me about it. The special (secret!) switch you use for CC vobs didnt work properly from a protected source. The packets were being copied over before being decrypted. I hope to have 3.2.3.0 out soon but as you've not moaned to me personally, I guess it's not that big a deal ;)

[Eyes`Only]

thanks for the clarification, light_uk. I would've never ever found that bug you mentioned, as I decrypt everything to .iso before I started demuxing, like everyone should :)