Explanation of DVD Space Requirements ?

[mbluett]

I just went through the process of converting a PAL dvd to an NTSC dvd which worked fine. Of course you loose the menus, but those can be re-created.

During the process I was trying to determine the best tools to use. I started with ConvertXtoDVD v:3.4.8.123 and then added a menu system with Ulead DVD MovieFactory v6.10.0194.3. I used MovieFactory because I didn't want to take the time to figure out how to do the menus nicely in ConvertXtoDVD.

The strange thing is the method #2 required one DL DVD; whereas, method #1 required one regular DVD.

What I don't understand is why method #2 results in 2 Gig more space required. Any ideas?


Method #1:

5 files output from Ulead v6.10.0194.3:
file sizes: 1,000,026 k (4 files)
last file size: 115,458 k

Video: 9608 Kbps CBR, 720*480 (16/9) at 29.970 fps, MPEG-2 (NTSC)
Bits/(Pixel*Frame) : 0.928
Audio: 192 Kbps, 48 Khz, 2 Ch, AC3

Overall bit rate: 2602 Kbps (file #1), 86 Kbps (files #2 - #4), 2499 Kbps (file #5)

Method #2:

I then did another test where I allowed Ulead DVD MovieFactory to import the files directly from the PAL dvd and then added menus. This process produced the following:

Files imported directly (from PAL files) into Ulead, menu added:
7 files output:
file size: 1,000,110 k (6 files)
92,344 k

Video: 4000 Kbps CBR, 720*480 (16/9) at 29.70 fps, MPEG2 (NTSC)
Bits/(Pixel*Frame) : 0.386
Audio: 224 Kbps CBR, 48 Khz, 16-bits resolution, 2 Ch, Mpeg-1 Audio Layer 2

Overall bit rate: 3864 Kbps (file #1), 87 Kbps, 3901 Kbps, 87 Kbps, 87 Kbps, 3865 Kbps, 3536 Kbps (file #7)

[filmboss80]

Bitrate is part of the issue, and Ulead may be reencoding the video you already encoded once with ConvertXtoDVD. (Frankly, I cannot see much logic in your methods.) Although there is a top bitrate listing of 9608 kbps in the method 1 video encoding, the 3 resulting files are showing bitrates well under 3000kbps. The set bitrate in method 2 appears to be 4000 kbps, and the overall bitrate of 4 resulting files are just under that range. (I don't know what those 86 and 87 kbps files are.)

But you have another situation going on. You have PAL sources being output to NTSC. How's that working out for you?

Your post also has the phrase, "I didn't want to take the time to figure out how to..." -- which is a bit of a wimpy cop-out; especially when you expect others to solve your problem for you.

I'm just sayin'...

[mbluett]

Posted by filmboss80: Your post also has the phrase, "I didn't want to take the time to figure out how to..." -- which is a bit of a wimpy cop-out; especially when you expect others to solve your problem for you.

Oh, pleaseeeeeeee!!!! The part that I didn't want to take the time to look into is constructing menus which has NOTHING to do with the issue I was interested in comments about.

Perhaps you might consider getting off your high horse for a moment OH NOBLE ONE!!!!

[manono]

I used MovieFactory because I didn't want to take the time to figure out how to do the menus nicely in ConvertXtoDVD.

Yeah, but if it's being reencoded by Movie Factory (as it seems), then you'd better figure out something. I agree with filmboss80 that your workflow leaves a lot to be desired.

[jagabo]

Method #1:

5 files output from Ulead v6.10.0194.3:
Video: 9608 Kbps CBR...
Overall bit rate: 2602 Kbps (file #1), 86 Kbps (files #2 - #4), 2499 Kbps (file #5)

Ulead did not deliver the requested bitrate here. Or the source was already DVD compatible so it didn't have to reencode.

Method #2:
Video: 4000 Kbps CBR...
Overall bit rate: 3864 Kbps...

Ulead delivered about the right bitrate in this case.

file size = bitrate * running time

The first encoding should have been more than twice the size (9608/4000) of the first.

Note that Ulead DVD Movie Factory will reencode files that are not DVD compliant (or if you make any changes to the video, like trimming out ads). It will use the bitrate specified in the project settings when it reencodes.

[mbluett]

Method #1:

5 files output from Ulead v6.10.0194.3:
Video: 9608 Kbps CBR...
Overall bit rate: 2602 Kbps (file #1), 86 Kbps (files #2 - #4), 2499 Kbps (file #5)

Ulead did not deliver the requested bitrate here. Or the source was already DVD compatible so it didn't have to reencode.

Well, it may not have re-encoded it. But if what I am hearing is correct (i.e., if I make changes it should re-encode) then it should have re-encoded with Method #1 as I had to split the movie up into segments. Unless, splitting a movie is not enough to cause a re-encode (which makes sense to me).

Method #2:
Video: 4000 Kbps CBR...
Overall bit rate: 3864 Kbps...

Ulead delivered about the right bitrate in this case.

file size = bitrate * running time

The first encoding should have been more than twice the size (9608/4000) of the first.

Note that Ulead DVD Movie Factory will reencode files that are not DVD compliant (or if you make any changes to the video, like trimming out ads). It will use the bitrate specified in the project settings when it reencodes.

I would agree with your premise the "The first encoding should have been more than twice the size (9608/4000) of the" 2nd. However, that is not what happened. The 2nd was increased by 2 Gigs. Regardless whether the method that I used was inefficient or not, this is the issue I was most interested in comments on: Because it makes no sense to me. I think there is some inefficient coding in MovieFactory. The main point here is that ConvertXtoDVD produced a fileset that would fit on a regular DVD; whereas, MovieFactory produced a fileset that required a DL DVD. Both of these utilities converted directly from the same source. In the case of MovieFactory I was required to split the movie into segments, but that is all the editing I did.

Although the following condition is slightly different it still reflects a strange result from MovieFactory. I first noticed this condition occurring when I would take an MPEG NTSC movie I had recorded on my HTPC, cut out the commercials and then "join" the segments (using a bitrate of 8000 Kbps). The crazy thing is, the original MPEG would have fit on a regular DVD; however, the edited re-joined version requires a DL DVD (and yes I know re-encoding is occurring). Even reducing the bitrate to 4000 Kbps doesn't allow it to fit on a regular DVD. What is more, I don't remember this happening with MovieFactory v4 (which could use a max of 7000 Kbps).

[jagabo]

I would agree with your premise the "The first encoding should have been more than twice the size (9608/4000) of the" 2nd. However, that is not what happened. The 2nd was increased by 2 Gigs. Regardless whether the method that I used was inefficient or not, this is the issue I was most interested in comments on: Because it makes no sense to me. I think there is some inefficient coding in MovieFactory. The main point here is that ConvertXtoDVD produced a fileset that would fit on a regular DVD; whereas, MovieFactory produced a fileset that required a DL DVD.

It's simple: Convertx produced files that are about 2500 kbps and they were DVD compatible so they didn't need reencoding. The second method reencoded with about a 4000 kbps bitrate because it had to do a PAL to NTSC conversion. Hence the bigger files.

Maybe Movie Factory has gotten smarter about reencoding if you only make simple cuts. I'm still on version 4 myself.

Both of these utilities converted directly from the same source.

The source doesn't matter. File size = bitrate * running time. If you want smaller files use a lower bitrate.

Although the following condition is slightly different it still reflects a strange result from MovieFactory. I first noticed this condition occurring when I would take an MPEG NTSC movie I had recorded on my HTPC, cut out the commercials and then "join" the segments (using a bitrate of 8000 Kbps). The crazy thing is, the original MPEG would have fit on a regular DVD; however, the edited re-joined version requires a DL DVD (and yes I know re-encoding is occurring). Even reducing the bitrate to 4000 Kbps doesn't allow it to fit on a regular DVD. What is more, I don't remember this happening with MovieFactory v4 (which could use a max of 7000 Kbps).

Once again: file size = bitrate * running time. If you want smaller files use a lower bitrate. If you use too low a bitrate the image quality will be poor.

[Nelson37]

You have apparently discovered that if you encode the same set of movies with two different encoders with two different sets of parameters, you will get two different file sizes.

This is correct, different encoders will produce different filesizes, even if you use the SAME set of parameters.

For instance, many programs will not accept AC-3 audio and will automatically convert it to LPCM, resulting in a dramatic file size difference.

Reading carefully your methods, I am unable to determine exactly what is going on.

Joining files does NOT, repeat NOT, involve any bitrate settings of any kind. ENCODING does.

Seperate your processes, compare similar processes without anything extra going on, examine bitrates and audio types. You are correct that something has changed to create the size difference. It may very well be something that you requested.

[jagabo]

different encoders will produce different filesizes, even if you use the SAME set of parameters.

Just so the OP isn't confused: if you specify the same bitrates (audio and video), and the encoders can deliver those bitrates accurately (not all do), the files will be very close to the same size.

And just for completeness, in the equation:

file size = bitrate * running time

The bitrate is the sum of the average audio and video (and any other data you might be including) bitrates. And there is a little bit of overhead (typically less than 1 percent) for the MPG and VOB containers. And if you're making a DVD you need a little space for menus and such.

A good tool to examine bitrates in MPG/VOB files is GSpot.

[mbluett]

It's simple: Convertx produced files that are about 2500 kbps and they were DVD compatible so they didn't need reencoding. The second method reencoded with about a 4000 kbps bitrate because it had to do a PAL to NTSC conversion. Hence the bigger files.

Maybe Movie Factory has gotten smarter about reencoding if you only make simple cuts. I'm still on version 4 myself.

The first method did involve a re-encoding as there was a conversion form PAL to NTSC. In fact, both methods involved re-encoding because they were from the same PAL source. First method converted from PAL to NTSC using ConvetXtoDVD and the 2nd method converted from PAL to NTSC using MovieFactory. The reason you may have been confused is that in Method #1 I subsequently ran the ConvertXtoDVD files through MovieFactory to add menus. But regardless, the files produced by ConvertXtoDVD and MovieFactory are quite different in size. The strange thing is that MediaInfo claims a 9608 Kbps bitrate on the video produced by ConvertXtoDVD and MediaInfo claims 4000 Kbps bitrate on the video produced by MovieFactory. And yes, MovieFactory did convert the audio from AC3 to MPEG 1 Layer 2. However, I doubt the audio change would make a 2 Gig difference. The smaller bitrate MovieFactory produced files that would require a DL DVD; whereas, the ConvertXtoDVD files would fit on a regular DVD. This makes no sense, unless the difference has to do with the level of compression used.

There is something behind the scenes that is going on with MovieFactory that I have no control over.

[mbluett]

You have apparently discovered that if you encode the same set of movies with two different encoders with two different sets of parameters, you will get two different file sizes.

You don't get it. I know that they will create different file sizes based on settings. That is not the issue. The issue is that MovieFactory using 4000 Kbps produces files that are 2 gig bigger than ConvertXtoDVD using 9608 Kbps. If anything I would think ConvertXtoDVD should have been the bigger set of files.

And yes, I understand that different encoders can produce different file sizes. But a 2 Gig difference especially when the bitrate (4000 Kbps) of the larger fileset is less than half the other (9608 Kbps). That makes no sense at all unless there is a significant inefficiency in MoveFactory's design (including the encoder it uses).

[jagabo]

The Convertx files are not 9608 kbps, they are about 2500 kbps. MediaInfo only reads the MPG header to determine the bitrate. The header usually indicates the max bitrate in a VBR file, not the average. Use GSpot, it will examine the entire MPG/VOB file and report the average bitrate.

[mbluett]

The Convertx files are not 9608 kbps, they are about 2500 kbps. MediaInfo only reads the MPG header to determine the bitrate. The header usually indicates the max bitrate in a VBR file, not the average. Use GSpot, it will examine the entire MPG/VOB file and report the average bitrate.

This raises a question: If MediaInfo is reporting the actual video bitrate then I would think that it would be relative to what the actual file size is to be. Or is the actual file size relative to the average?

If the file size is based on the average then what would be the significance of MediaInfo reporting actual bitrate?

[jagabo]

MediaInfo reports the bitrate indicated in the first header of the MPG file (it makes no attempt to verify if the value is correct). This is usually the max bitrate in a VBR encoded file, not the average bitrate. This is not the "actual" bitrate. The actual bitrate varies during the video. Some shots will get more bitrate, others less. The average bitrate multiplied by the running time determines the size of the file. The only use for the max bitrate is to determine if the bitrate will exceed the DVD spec (about 10,000 kbps total for audio + video + subs) at any point during the duration of the video. Of course, in a CBR encoded video the average and max are the same (in theory, in reality they may still vary a little bit because the encoder can't make every frame or every GOP exactly the same size).

[Nelson37]

Programs which attempt to report the bitrate of a file are simply not accurate, If you want a correct answer, get the number of frames or running time plus the file size for the VIDEO PORTION ONLY, and do the math. That will tell you what the average bitrate actually IS, as oppossed to a guess. The audio format is different and has been changed. Eliminate this from the comparison.

Let's try this another way. What encoding parameters did YOU, the user, specify? While these are not totally accurate, either, they will offer a basis for comparison.

Demux the video from the audio and compare differences. Do not guess or make logical inferences, find out the actual answer.

Have you checked running times? One encoder or the other may have skipped a section of the video.

Why are there 7 files in one, and 5 files in the other? Skip the menus, use the same files, and compare apples to apples.

You must do EXACTLY THE SAME operation in both progs in order to find out what is different. Menus can balloon to tremendous sizes with some progs.

[jagabo]

If you want a correct answer, get the number of frames or running time plus the file size for the VIDEO PORTION ONLY, and do the math.

That is basically what GSpot does when Full File Scan is enabled.

[manono]

You have apparently discovered that if you encode the same set of movies with two different encoders with two different sets of parameters, you will get two different file sizes.

You don't get it. I know that they will create different file sizes based on settings. That is not the issue. The issue is that MovieFactory using 4000 Kbps produces files that are 2 gig bigger than ConvertXtoDVD using 9608 Kbps. If anything I would think ConvertXtoDVD should have been the bigger set of files.

No, you don't get it. 9608 is the maximum bitrate set by the encoder. The average bitrate is closer to 2600, Of course the file size jumps after being reencoded to 4000 CBR. And using CBR encoding is not the way to encode. Why are you even here asking for advice when all you want to do is argue and contradict? The fact remains that you don't know what you're doing.

You might try doing the conversion using FAVC, having it save out the elementary streams for authoring using a program guaranteed not to reencode, something like the freeware GUI4DVDAuthor or DVDAuthorGUI.

[mbluett]

Why are you even here asking for advice when all you want to do is argue and contradict? The fact remains that you don't know what you're doing.

The fact that I don't have all the answers is WHY I am here. If I knew all the answers I wouldn't be asking questions now would I?

I am not arguing. I am pointing out anomalies that don't make sense to me. I have no idea of your knowledge or expertise and so I sometimes challenge a response. My intention is not to insult, unless I am first insulted. It is very easy to get ones back up due to a misinterpretation of words.

When I said "You don't get it.", it seemed to me that you didn't because of the data I was believing to be correct. Obviously my interpretation of it was not correct because of things I did not know. Hence the reason why I am asking questions!!!!

Wait a minute, who the HELL are you? I did not contradict you and what right do you have in asserting such nonsense?

And thanks very much for pointing out that I don't know what I am doing. That makes me feel REALLY good!!!

Why don't you crawl back under the rock you came out from.

[Nelson37]

Gonna give you some free advice, bucko. Stop bitching, shut up, and answer questions.

YOU may not know who all you have just pissed off, but I do.

First, the "information" you supplied was confusing, incomplete, and damn near worthless. The assertion that you do not know what you are doing was correct, and I agree with it.

Now, do you want to CHANGE that situation, or just bitch about it?

I asked you the SPECIFIC question, "What bitrates did you specify?" It has been explained to you, and I will emphasize, the bitrate numbers you are citing are NOT ACCURATE. What numbers did you input???

You have two files encoded from the same source, of different bitrates and due to that, different filesizes. Your question would seem to be how they got that way. The way to get to the answer is to provide responses to specific questions.

You have already most likely eliminated on of your best possible sources to arrive at a conclusion. Wanna try for two?

[mbluett]

Gonna give you some free advice, bucko. Stop bitching, shut up, and answer questions.

I am going to give you some free advice, BUCKO!!!!

Everything was OK until this "manono" character showed up on the scene. I did not mean any disrespect to you. I meant disrespect only to this "manono" character as he was the first to be blatantly disrespectful. All I was doing was trying to clarify my knowledge.

And now you and he have blown things totally out of proportion. And now finally my advice: I think you should take a closer look at the conversation and tell me where I have insulted anyone other than this "manono" creep who all of sudden came on the scene with nothing but derogatory remarks to spew at me. How do you expect I would react to him?

Again I meant no disrespect to you or anyone before.

[Nelson37]

First, it was ME to whom you stated "you don't get it". Based on a lack of understanding on your part. If you have not yet figured this out, you are in no position whatsoever to tell virtually anyone on this site that THEY don't get it.

It is as though you are stating that you saw a horse that was taller than an elephant, and are offering detailed analysis of evolutionary theory as to why this should not be so, when you do not realize that what you thought was a horse is actually a giraffe. To top if all off, you then insist that the game wardens are wrong, not you.

This "manono character" is one of the two or three most knowledgeable posters on this site.

I have asked you SEVERAL TIMES to answer a specific question, designed with the benefit of almost 10 years of experience, thousands of test encodes, and hundreds of hours reading and researching, to get at precisely what the problem is.

You'd rather complain and moan than to provide information intended to solve YOUR problem.

If your next post does not answer the question posed to you, then you will get no further help from me. Last Chance.

[manono]

Wait a minute, who the HELL are you? I did not contradict you and what right do you have in asserting such nonsense?

If you'll read up a ways, you'll notice that I was the 2nd respondent to you, backing up filmboss80 to whom you had already taken offense, for no good reason. He probably gave up in disgust after quickly figuring out where this thread was headed. My first response was polite; my second one less so as by then you had also insulted Nelson37 and used way too many words but without saying much of anything relevant to your problem. I didn't accuse you of contradicting me, now did I? Nor did I assert any nonsense. I guess Nelson37 is going to stick it out. Maybe jagabo will as well. As for me, good luck and good bye.

[mbluett]

First, it was ME to whom you stated "you don't get it". Based on a lack of understanding on your part. If you have not yet figured this out, you are in no position whatsoever to tell virtually anyone on this site that THEY don't get it.

My apologies if I did not word things in such a way as to not offend you. It seemed to me from your explanation that you did not understand the issue I was trying to convey. Perhaps you were, but my interpretation of what you wrote was not that and I am sorry for any misunderstandings.

In any case, Jagabo's responses proved to be quite helpful and as a result I need no further help at this time.