2ch and 5.1ch audio in Scenarist

[Doom9]

I'm in the process of creating a 1 VTS 4 Title/PGC DVD that has 4/2/1/0 soundtracks respectively. Title 1 has 3x 384kbit/s 5.1 AC3 and 1x 192kbit/s 2.0AC3 audio, Title2 has 1x 5.1ch and 1x 2.0ch, Title3 has 1x 2.0ch and Title4 has no audio.. while I can create my scenario when I want to compile I get errors like: Error Number of channels are different between trainingday AC3 T01 3_2ch(7) and pgc3 AC3 T05 2_0ch 192Kbp(2).
Error LFE channel are different between trainingday AC3 T01 3_2ch and pgc3 AC3 T05 2_0ch 192Kbp.
Error Bit rate are different between "AC3 Audio "trainingday AC3 T01 3_2ch""(384000) and "pgc3 AC3 T05 2_0ch 192Kbp"(192000).
Error The Audio Attribute(Language, coding mode and so on) in PGC<pgc3-t-pgc>:Stream<0>:Title<Title_3> is different from The Reference PGC<trainingday-t-pgc>
anybody knows a way around this?

[TRILIGHT]

Well, the only thing that I have found so far is to "trick" Scenarist much in the same way that I did for getting my multi-PGC, multi-angle stuff to work.

It appears that Scenarist is comparing bitrates on the given audio tracks across all PGC's in a given Title set. For instance, if Track1 has 192kbps as audio track 1 and Track2 has 384kbps for audio track 1, it complains that the bitrates are not the same.

Take this same situation but add a small 384kbps clip as audio track 1 on Track1 and it lines up with the 384kbps on Track2 and Scenarist does not complain anymore. Now, granted, this does not necessarily solve the problem as you obviously have the need to line this up as the original was. However, if it works as it did in my case, and you're re-integrating into the original DVD IFO structure, it may ignore anything you put on tracks not accessed originally anyway! That, of course, would be the best solution. All you would have to worry about is "fooling" Scenarist and then let the commands in the original IFO's do the work for you.

However, I still have to wonder if there is not another way if my above suggestion does not work. Perhaps it is because you are using AC3 files that have already been compiled? Maybe if it was truly "from scratch" and you were using WAV files and let the built-in Scenarist AC3 encoder do the job, perhaps it wouldn't complain. I don't know.

Anyway, about the only suggestion I can give you is attempt to line the bitrates up as I suggested above. Perhaps the instructions in the original IFO's will alleviate any anomalies introduced. Sorry, but it's the best suggestion I have so far.

[Doom9]

It appears that Scenarist is comparing bitrates on the given audio tracks across all PGC's in a given Title set. For instance, if Track1 has 192kbps as audio track 1 and Track2 has 384kbps for audio track 1, it complains that the bitrates are not the same.
I was having the same suspicion. And having another look at the audio channels shows the following:
PGC1: 0x80, 0x81, 0x82 = 5.1AC3, 0x83 = 2.0AC3
PGC2: 0x80 = 5.1AC3, 0x83 = 2.0AC3
PGC3: 0x84 = 2.0 AC3
PGC4: no audio

Interesting, isn't it? Though as there appears to be no 0x81/2 in PGC2 I'm wondering if it wouldn't be possible to simply select a stream number for an audio track to be added..

[mpucoder]

Is PGC1 0x80 the same bitrate as PGC2 0x80?
It is correct to compare bitrates/channels/encoding etc for the entire title set, as there is only one set of audio attributes for the entire vts. look at http://mpucoder.kewlhair.com/DVD/ifo.html#audatt
This is also why you see no 0x81 or 0x82 in PGC2. I'm curious as to why 0x84 was used for PGC3

edit: I see what Trilight is getting at, Scenarist expects the first PGC (what it calls the reference) to define all possible audio tracks that are used in other program chains.

[mpucoder]

Did a little more thinking on the subject. Scenarist is trying to tell you not to re-use a stream number unless it matches all the attributes listed in that table exactly. If it differs, assign the track to a new stream number.

[Doom9]

attributes of 0x80 in PGC1 matches 0x80 in PGC2, and 0x83 in PGC1 matches 0x83 in PGC2. Dunny about the 0x84 in PGC3 either.. at first glance it also appears to be the same..
I've added the original ifo so you can have a look at this, too.

I've now tried this... define PGC1 as usual with all the correct languages.. then in PGC2 add the 5.1 track 3 times, uncheck it (click on the checkmark on the left of the audio stream) so that there's only one 5.1 stream checked, then add the 4th stream (2.0ch), and the same in PGC3 (didn't want to add yet another channel so far).. finally ti compiles if the language settings for each track match in each PGC.. but now I have to re-encode.. bitrate too high :( If you have any other ideas let me know

[Eyes`Only]

I've had this issue and can offer my solution.

I created 'filler ac3 tracks', to match the format of PGC1. I took an .ac3 (very very small one, to not use much space!), and used SoftEncode to convert it to the appropriate number of channels, and named it stuff like 4chanfiller.ac3. Usually there's more than one audio track that is like that also, so I would use softencode once again and this time create another filler track to match the third audio format. Then, put these small fillers into tracks where your 0byte ac3s were.

It worked for me, hope it helps you also.

[Doom9]

thanks for the tip.. using 1 ac3 frame dummy track taken from pgc1 works.
now I have another thing.. the disc has about 20 subtitle channels.. quite obviously I don't need all of them so I settled for 3, processed them accordingly and scenarist is currently encoding them.. is there any way I can get the rest of the subtitle streams out of the original ifo without having to actually do the stripping operation on the original ifo/vob collection?

[Eyes`Only]

possibly when you are done with your final product, you can run ifoedit on your reauthored .ifo and tell it to strip the streams you dont want from the .ifo?

[Doom9]

well.. so far it worked but I screwed up in the subtitle department so I have to re-do it.. and then there's the whole burning thing.. though I don't think ifoedit would be the solution.. you'd have to use a regular ripper that can strip streams without renaming the remaining one (if I'm not mistaken if you strip stream 0x80 using ifoedit the old 0x81 becomes the new 0x80 and that's not what I want).