View Full Version : 4G files from a predicted 4.31G (is IC 8% out?)
MackemX
23rd February 2003, 17:48
using IC I have just backed up Back To The Future part 1 and got a resulting file of 4.37 GB (4,698,556,416 bytes)
talk about close and being lucky 1st time :D
I oversized to 4.71Gb, but I wrote the figures down 1st to get an indication of what is going on regarding my issue with undersizing
I had 3 titles I could adjust and the menu makes it 4 out of a possible 17
menu=90MB
title1=5.35Gb
title3=1.59Gb
title14=19mb
plus very small titles=7.06Gb which is also size of my ripped folder
the info in the cellset window for main movie (title1) was
4.19(5.35)
3.23(3.81)@76.93%
and the resulting file was 2.99(3.4) after putting it in IC again
& title3 was
1.51(1.59)
773(861) @ 50%
and 834(0.9) again in IC
others too small to show but these 2 above will do for my reference
doing the maths I can now see that it's an 8% difference between what IC predicted to fit onto 4.31Gb and the actual % needed to fill disk
title1 = 3.23(predicted)/2.99(actual)=1.0803 (+-0.003) due to inaccuracy of filesizes only shown in Gb
title3 834/773=1.0789 (bit more accurate due to more accurate filesizes due to MB shown)
so basically it's just under the 8%
this 8% difference relates to the transcoded size of each title and the actual outcome
so using this formulae in my movie title originally with the predicted title1 size of 2.99Gb then adding 8% of 2.99 to it making 3.23Gb and so on with the rest of the titles would have saved me all the bother of guessing @ 4.71Gb
the actual slider bar % increase relating to title1 is 5.61% from 71.32% to 76.93% (add 8% of predicted transcoded size to transcoded size and slide bar until it transcoded size reaches that size)
I reckon 7% is a safer margin due to only 2 decimal places for Gb not giving the actual size of file correctly
I'm gonna try again with BTTF 2 with an 7.5% increase and will post the info, but if anyone else can add the before and after info I would appreciate it (can I ask people if possible to write down the figures before and after like I have including disc totals & % settings etc)
I hope you can understand which way I came to this conclusion, and if it's totally wrong which it probably is then I will keep looking for the answer
p.s. if you do add the extra % and the file is tadge too big at the end just run ONE of the smaller files through IC again (only takes a few mins) then use IFOEDIT to reinsert it into the main files, so you don't have to run the whole process again (haven't tried it but surely it should work)
mrbass
23rd February 2003, 22:29
excellent detective work...one small thing to try. Keep all audio tracks (don't uncheck any of them) and see if this theory still holds true. On pinnacle site it mentions something to this effect that the calculation doesn't take into account unchecked audio files.
Or better yet just add the size of the audio excluded (french, directors commentary, etc.)...did that make up the 8% slack?
MackemX
23rd February 2003, 22:40
just completed disc 2 and had only 50MB to spare and I used 7.5% (wish I had used 8% now!) :D
predicted size was 4.61Gb but end result was 4.32Gb so difference was 0.29Gb whereas disc 1 had a predicted of 4.71Gb so if I had used 4.71Gb for disc 2 it probably would have just been over
I will update post later with figures to show exactly what I did
but if people could write down all the figures it may help me calculate what happens with different files etc
I think audio is not really the problem but it does increase missing filespace if unselected, as the audio is a constant size whereas the video is a variable
the more audio you keep, the total transcoded video size is smaller so the error will be less (hope you know what I mean)
so the more audio you take out the more you allocate to the video making a gigger margin of error (hope you know what I mean)
that may be why I have gotten files as low as 3.92Gb, probably because I stripped more than just the DTS language
e.g if the DTS soundtrack is 600MB and the foreign is 300MB making 900MB more available for the movie then really you should add 8% of 900 to the 900 which is 972MB
I think thats whats happening
MackemX
23rd February 2003, 22:46
Originally posted by mrbass
excellent detective work...one small thing to try. Keep all audio tracks (don't uncheck any of them) and see if this theory still holds true. On pinnacle site it mentions something to this effect that the calculation doesn't take into account unchecked audio files.
Or better yet just add the size of the audio excluded (french, directors commentary, etc.)...did that make up the 8% slack?
I'm sure I tried it before keeping all audio's as I stripped them 1st using ifoedit only to still get a smaller size as I thought audio was the problem
what results do you get if you do keep the audio's?
the more figures people post the quicker I can work it out
info would be appreciated
e.g this is my 2nd disc info from BTTF fitting to 4.31Gb
menu
62.32
43.56 @ 60.06%
Title 1
5.00(5.89)
3.21(3.54) @ 64.24 (missing audio 660MB)
Title 2
1.13(1.18)
580(634MB) @ 50.31
Title 8
138(144)
69.29(75.69) @ 50.31
Title 13
17.99(19.21)
9.05(10.27) @ 50.31
all the rest @100% but very small in total
total disc size 7.30Gb(7475MB)
mrbass
23rd February 2003, 23:41
specifically I'm reffering to this posted on pinnacle
The transcoded image is oversized, respectively the error message "the medium is out of space" occurs.
Question
The transcoded image is oversized, respectively the error message "the medium is out of space" occurs.
Answer
After the removal of no longer required audio-tracks(e.g. the german or french language)to gain additional space for the main video, the calculated/estimated size is too large.
Solution:
Update installation (problem solved)
...I'll post sometime later tonight...perhaps..if I got time to do some testing.
I know this is OVERSIZED and not UNDERSIZED but I bet that 7.0.0.80 probably has near accurate results and this bug fix created a new bug perhaps....ok now I haven't a clue what I'm talking about.
MackemX
23rd February 2003, 23:53
http://pinnacle.custhelp.com/cgi-bin/pinnacle.cfg/php/enduser/std_adp.php?p_sid=OBUpfCCg&p_lva=&p_faqid=1946&p_created=1043764646&p_sp=cF9zcmNoPTEmcF9ncmlkc29ydD0mcF9yb3dfY250PTIxJnBfc2VhcmNoX3RleHQ9JnBfc2VhcmNoX3R5cGU9MyZwX3Byb2RfbHZsMT00OCZwX3Byb2RfbHZsMj01MSZwX2NhdF9sdmwxPX5hbnl_JnBfc29ydF9ieT1kZmx0JnBfcGFnZT0x&p_li=
yeah I think they fixed the oversizing bug and somehow its in reverse :D
I would appreciate some figures from your testing if you could mrbass
I'm setting Simpsons disc2 away now with no audio stripped, last time I got 3.99Gb so I wonder what will happen this time with 8% to total transcoded video files theory?
EjectButton
24th February 2003, 00:41
here are some more figures, they might be worthless but they might also help confirm something so I will post my results.
The "start size" is the original size of the ripped files, movie files and extras, basically everything in the original video_ts dir. (I didn't think to write them down the first 3 times I transcoded so that's why they aren't there).
the "E" is a rough estimate of the size of extras being ripped out by IC.
"target size" is the size I told IC to make the final transcoded image.
"actual size" is what the final transcoded image turned out to be.
"ratio" is the size of the output vs what IC said it would be.
"title" is the disc tested on.
(start size)--(target size)--(actual size)--(ratio)--------(title)
------------------------------------------------------------------------------------
??? -------- 4.81---------- 4.36-------- 90.64%-------- citizen kane
??? -------- 4.78---------- 4.19-------- 87.66%-------- cowboy bebop
??? -------- 4.81---------- 4.34-------- 90.23%-------- simpsons s2d3
7.27(0.4E)-- 4.81---------- 4.39-------- 91.27%-------- x-files s1d1
7.33 (0 E)--- 4.81---------- 4.53-------- 94.18%-------- world at war d1s1
yea I know this is a mess (tabs don't show up it seems), and yea I know it would be more useful if all the numbers were there but I wasn't really thinking about that stuff when I started using IC, I'll take better notes from now on =/
MackemX
24th February 2003, 00:44
I need all these figures really
menu
62.32
43.56 @ 60.06%
Title 1
5.00(5.89)
3.21(3.54) @ 64.24 (missing audio 660MB)
Title 2
1.13(1.18)
580(634MB) @ 50.31
Title 8
138(144)
69.29(75.69) @ 50.31
Title 13
17.99(19.21)
9.05(10.27) @ 50.31
all the rest @100% but very small in total
total disc size 7.30Gb(7475MB)
but any info is a help, cheers :D
MackemX
24th February 2003, 00:54
here are my BTTF disc 2 results
menu
62.32
43.56 @ 60.06%
Title 1
5.00(5.89)
3.54(3.54) @ 64.24
title 2
1.13(1.18)
580(634MB) @ 50.31
title 8
138(144)
69.29(75.69) @ 50.31
title 13
17.99(19.21)
9.05(10.27) @ 50.31
all the rest @100% but very small in total but I dont think 100% transcoded files affect the end result
total disc size 7.30Gb(7475MB)
I had set my menu's & extras to what I wanted and the 8% I wanted to add to Title 1 (main movie)
to work out what I could add I took the total of each predicted filesize using MB as units
43MB+3625MB(3.54Gb)+69MB+9MB= 4325MB or 4.226Gb (remembering 1GB=1024MB)
then I calculated 7.5% of that total(just to be safe) = 324MB or 0.317Gb
I took 5MB off just in case for rounding down and this made 319MB(.03115Gb) to add title 1
this then gave me 3.5215Gb but I decided to play it safe again and reduced it again to 3.51Gb @ 70.25%
well, guess what
final disc size was 4428MB only 61MB shy
if I had used 8% originally without taking off any safety margins I should have used 3.547Gb which is an extra 39MB I should have added yet again!
that would have been even closer to 4489MB barrier but because of Gb being only 2 decimal places a Gb figure can be out by as much a 9MB!, so I played it safe and rounded down
gonna try Simpsons Disc 2 again as last time I got 3.99Gb but didnt extract any audio only reduced video so I will do the same again and add the 8%
stupid
24th February 2003, 00:57
Question
The transcoded image is oversized, respectively the error message "the medium is out of space" occurs.
Answer
After the removal of no longer required audio-tracks(e.g. the german or french language)to gain additional space for the main video, the calculated/estimated size is too large.
Solution:
Update installation (problem solved)
where can we get the udpate?
EjectButton
24th February 2003, 00:58
that last one, the "world at war" is the most pure one on there
the starting size of the video_ts dir was 7.33 GB
I dropped the menu quality all the way, IC claims (221 MB) > (84.73 MB)
there was only 5 tracks listed, the last one was a 14 kb track that I removed, the other 4 tracks were the main video tracks and they could not be downsampled independently (you moved the slider for one and the slider moved for all)
IC said that the video data size was 6.69 GB, I dropped this to 64.14% in IC and it said the transcoded size would be 4.29 GB
there was only one audio channel, (english ac3 stereo 224kbit) that was 342 MB and I didn't touch it
there were no subtitle tracks or any other extras
the output was 4.53 GB
MackemX
24th February 2003, 01:00
Originally posted by stupid
Question
The transcoded image is oversized, respectively the error message "the medium is out of space" occurs.
Answer
After the removal of no longer required audio-tracks(e.g. the german or french language)to gain additional space for the main video, the calculated/estimated size is too large.
Solution:
Update installation (problem solved)
where can we get the udpate?
I think I already have the update, as none of mine have oversize
I have the trial version 7.0.0.91 (only 8 days left :()and it always undersizes
MackemX
24th February 2003, 01:03
Originally posted by EjectButton
the output was 4.53 GB
what version are you using ? and is it the trial of full?
EjectButton
24th February 2003, 01:06
full
7.0.0.91
EjectButton
24th February 2003, 01:36
MisterX-
I realize what I said might sound confusing since when someone says "the size" on a screen there are multiple sizes displayed so I took screenshots of the menus so everything will be clear
http://www.ejectbutton.com/TEST/instantcopy_info/
MackemX
24th February 2003, 01:49
Originally posted by EjectButton
MisterX-
I realize what I said might sound confusing since when someone says "the size" on a screen there are multiple sizes displayed so I took screenshots of the menus so everything will be clear
http://www.ejectbutton.com/TEST/instantcopy_info/
that's exactly what I want but what I need is what IC predicts will actually fit
can you start it again (or is it running?) so it shows a predicted size of 4.31Gb instead of 4.81Gb and I will have a guess at what you should set each to
no need to start processing just the beginning figures and I will post a % for you to try if you want to
I only need the 1st title pic as 1-4 are the same file and title 5 is small and still 100% and the Video tracks (menu) pic
cheers and thanks for the info so far
EjectButton
24th February 2003, 02:02
if I understood you correctly I stuck that at the end of the page now
as a side note, is the target of 4.31 used because there are certain discs that have this as a limit and that's the absolute smallest dvdr you will find or is it leaving space to leave the disc open (though I don't know why you would want to do that)
I only ask because the nero info tool lists my blanks as being 4.386 GB and I also successfully burned a 3.9 GB image before, yea I know this is only a difference of 80 megs or so but I was just curious.
MackemX
24th February 2003, 02:10
cheers
a blank DVD can have 4489MB of data written to it
or 4489MB/1024 = 4.38Gb like you said (or 1024*1024*4489=total bytes)
I think pinnacle use the .07Gb as a safety margin
EjectButton
24th February 2003, 02:22
if you want to test the math and make a prediction on what that disc should be set at to make it come close to fitting, I could try it and leave it encoding when I go to work in few min
MackemX
24th February 2003, 02:26
did u leave the menu @ 30% for that last update as somhow the predicted filesize of 4.31 which is 0.5gb less than 4.81Gb before
yet the size of transcoded is not 0.5Gb less but .54?
I'm reckoning about 61% should do it but I need to know if menu was @ 30% or 56% for the last pic
you don't know the video size of the 4.53Gb file you made by anychance? as it should be around 3.95+- .01Gb
cheers
EjectButton
24th February 2003, 02:32
yea i dropped the menu to 30% every time
unfortunately I don't have the 4.53 files anymore cause I deleted them when I saw they were too large to burn and the only info I took from them was the total file size
MackemX
24th February 2003, 02:48
but it's strange how the 4.81Gb file was 0.9Gb over the transcoded video size+audio (4.72Gb) which is exactly what the menu encoded down too in Gb from 221MB@30%
yet in the last example the difference is 0.13 so it looks like an extra 0.04Gb has appeared somewhere
so the total of video files is 3.75Gb+ menu of .13Gb =3.88Gb
add 8% = 4.19Gb for total transcode size or setting of 62.63%
still cant work out why it 0.04Gb out as this will affect calculations but hopefully not by much, I have included it as it is not accounted for
MackemX
24th February 2003, 03:00
If you have ran it Ejectbutton, I reckon you will get a file of 4.33Gb +-0.02Gb :D
MackemX
24th February 2003, 03:27
if I'd ignored the 0.04 I woulda done the following
3.75(transcoded) + 0.09(menu) = 3.84
3.84 + 8% = 4.1472 transcoded size or 61.991% on slider bar
but again because of the 2 decimal points it could be affected as it could be 62.136% if the 2rd decimal place is 0.009, so there is an margin of error @ 0.3%, but it's better to stick with the lower %
but I opted to include the .04 giving the 62.63% but then this could have also included another 0.03% (which works out at exactly 0.2GB when used with 6.69GB!), so it could have been 62.93%
this is nearly 1% higher than the 1st prediction in this post which would result in an extra 64MB (0.06Gb), so you can see how much not knowing the 3rd digit can affect results by, so its better to go with the lower ones and subtract 0.01 from total to be safer
It would be more accurate and easier if IC showed that 3rd decimal place, but you can't win em all
I slide the % bar using arrow keys in steps of .1% and watch the transcoded size go up in relation to setting to work out if the 3rd digit is a high no. or low no.
MackemX
24th February 2003, 06:29
well Simpsons came out at 4.15Gb (4256MB) well short of 4489 (233 to be exact)
but there was a strange problem regarding audio before processing with IC
it has 7 Titles with 1-6 for each episode and title 7 being very small, menu was also 37MB
4 audio tracks on each title, yet on 4,5&6, for some reason the totals do not show in IC as shown here
http://www.deano.dsl.pipex.com/ics.htm
If I add the 2 unticked soundtracks for the 6 titles, the total predicted only goes up by 0.2GB?!??!?, if I add just the one then it goes up by 0.1GB!!
this is wrong as it should go up by 0.4Gb as that is 12 soundtracks @ 33.6MB each on average which is 403MB=0.392GB not 0.2 as IC predicts!
so that's where the phanton 200MB must have went, somehow IC is still including it, why beats me but it may be wise to check the audio. (this is the 2nd time I have come across this)
and after running thru IC all the resulting Titles are all missing the 2nd Audio sizes shown in the bottom pic in that last link
so now take the phantom 202MB for the missing 6 unticked unaccounted for tracks and add 8% makes 219MB
add this to the 4256MB I got then it would be 4475MB which is only 12MB shy!
I will have to see if this was the case by running it again and adding the extra 219Mb between the 6 titles
:D i love mathematics
mrbass
24th February 2003, 06:47
Why doesn't it make sense? Isn't the last English audio directory's commentary which usually doesn't have a subtitles to it. Perhaps it's been a long day and I'm losing my mind arggh.
When you uncheck one title which other ones uncheck along with it. In other words..let's say for example you unchecked Title 3 does Title 4 go away too? If so that's why it wouldn't show the bitrate since it's redundant and tied to the same VTS.
hint/suggestion: try saving your screenshots in irfanview as .png and set compression level to 9 (which is highest) and you'll love the small file sizes and quality.
MackemX
24th February 2003, 07:06
the 6 titles are seperate as they are 6 episodes, I can untick any title I want
the audio's are linked but I think this is the case with all DVD's, and they are still shown with different values as the audio totals vary in size in relation to the length of the video file in the title
I wonder why does IC only shows the 1st 3?
is 23mins 05sec of 198Kbit equal to 33.62MB? (don't know the formula)
each episode has the 5.1/surround/French/directors on, in that order so I skipped the surround & French
just played the original, there are no French subs on eps 5&6!, yet the option is there!
have another look at the bottom pic in the link cos if I untick the 2nd audio(no total) it does not affect anything,it's a phantom audio :D
look at the video size of 605MB then add the 1st soundtrack of 77.56=682.56 leaving 8.44MB for subs, so where is the extra 33.5MB for the 2nd track?
there's somits up :D
p.s. thanks for pic tips
EjectButton
24th February 2003, 10:05
just got home, I didn't know about moving the slider with arrow keys, I'll use that from now on.
Anyway I redid the "world at war" disc and set the slider to 61.11% and it predicted an end size of 4.6 GB, I let it process and the end result was 4.39 GB
This is kinda what I expected, just by taking the first time I transcoded and looking at the percentage difference between the predicted result and the actual result I figured I would have to target 4.6 GB to get a full 4.3x image.
The annoying thing is I still don't know how to reliabily predict what the end size is going to be the first time, I can transcode once, get a worthless image file, then adjust assuming it will miss by the same percentage and get it on the second try, but that's obviously not a very good method.
it sort of seems like the percentage IC is off by decreases as size of the source files increase, or at least that's what I see but I haven't really done enough tests to be sure, but at 2 hours a pop it's a bit irritating.
MackemX
24th February 2003, 12:58
sorry to hear that it didnt work :(
but I couldnt understand why the difference in your last pic was 0.13 compared to 0.09 in the 1st example
now if the diff was 0.09 in the 1st place you should have ended up with 4.35Gb, any idea why the menu/extras came to 0.13 in that pic? as that 0.04 shouldn't be there
difference shown here
http://www.deano.dsl.pipex.com/diff.htm
Originally posted by MisterX
[B]if I'd ignored the 0.04 I woulda done the following
3.75(transcoded) + 0.09(menu) = 3.84
3.84 + 8% = 4.1472 transcoded size or 61.99% on slider bar
if the diff had been 0.09Gb then this would have then worked, and to be safe you could take off that 0.3% error margin to give 61.69%
If you had used the 61.99% chances are you wudda ended up with 4.37Gb BUT only if the diff was 0.09Gb, and I reckon 8% (what I used is the max), 7.5% should fit no problem
have you deleted the resulting PDI files or did you get to see how big the resulting files within them were?, as that would be helpful as to seeing how IC did deal with them
MackemX
24th February 2003, 15:37
I've just extracted Simpsons disc 2 and the resulting file is 4451MB
it's 38MB shy which is close enough for me :D
I added 216Mb to the 6 movie files transcoded sizes (36MB each) to replace the phantom 200MB
I won't bore you all with the exact figures I worked it out atfor this latest test but again it worked with a file between 4.32Gb & 4.37Gb
but I would suggest to get a closer result 1st time to do the following
1. set IC so reckons it will still fit
2. check all audio shows a total
3. add all the transcoded totals for seperate titles up even the unticked ones (1024MB=1GB) (careful not to double count linked ones) and add menu BUT disregard the ones @ 100%
4. now subtract (0.009Gb x seperate titles shown in Gb not MB) total due to IC totals inaccuracy (safety margin)
5. multiply this figure by 0.8 (0.75 if you dont wanna chance going over)
6. you can now adjust sliders (use arrow keys for more accuracy) to add this resulting extra Gb to the predicted total but subtract 0.01Gb again as IC does have an possible error of 0.09Gb when showing filesizes in Gb
7. set it away and it should be result in a file between 4.31Gb and 4.37Gb, the less you round down the more you risk going over 4.37Gb
I could write a simple spreadsheet but I ain't installed office on my home computer again since reinstalling (lazy!)
mrbass
24th February 2003, 17:15
that stretches my brain further than it can stretch. Either a simple javascript calc or dinky calc program will have to be written. Is there any other way (missing target more but being closer). Like if you set the slider to 4.6GB will you always underhit?
MackemX
24th February 2003, 17:19
Originally posted by mrbass
that stretches my brain further than it can stretch. Either a simple javascript calc or dinky calc program will have to be written. Is there any other way (missing target more but being closer). Like if you set the slider to 4.6GB will you always underhit?
that doesnt work as it seems to be affected by the total video size
the larger the video size the more it is out
i have written the spreadsheet and you can even add a risk factor from 0% to 100% :D
I can't upload my spreadsheet yet but I can email it to if you wanna try it
it only 9kb
MackemX
24th February 2003, 17:22
Originally posted by EjectButton
Anyway I redid the "world at war" disc and set the slider to 61.11% and it predicted an end size of 4.6 GB, I let it process and the end result was 4.39 GB
I suggested a % which I shouldn't have (sorry:() but suggested you add anything upto a max of 0.29Gb, as if you look at my previous posts I was rounding down (so you had 4.61 but it should have been 4.59 or less
I get this figure from the using the formula in the previous post
I would get
3: 3.75+.0.13=3.88
4: 3.88-.018=3.8237
5: 3.8327*.0.8=0.305896 (7.5%=0.2875)
subtract 0.01Gb for extra safety margin and round down
6: so I would add between 0.27-0.29Gb to the slider bar to make it 4.6Gb
you can see that even a difference of adding 0.5% is 0.02Gb so it's still a chance if you wanna squeeze it all on but it's better than just guessing
I've wrote a daft little spreadsheet and it does all the work for you and you can even set the risk factor on how close you really want to be to 4.37Gb :)
needs some testing but looks ok so far as it spits out a prediction of 4.59Gb for your figures Ejectbutton
p.s. please ignore the formats as I had to use spread32.exe
like Ejectbutton mentioned the bigger the original the more the slider bar should be up and this gives that effect
the more times I try it the more I will fine tune the margins, but its doing fine so far
schlaufer
24th February 2003, 19:42
Hi,
it seems that thinks are not as easy as you guess. The over (or under-)shoot is really not linear, not even close (I think it is not even continuous differentiable). Since the whole thread is about numbers, I can publish my too to the problem:
Movie: 3,65 GB , 2x577 MB AC3 Audio (a former DVD9->DVD5 conversion extended with second audio track).
As usual I start with slightly above 4,60 GB (this turns out to be a good starting value for 2 AC3/5.1 audio tracks). After that I used Newton's fix point iteration algorithm to find the right value for the desired output size of appr. 4,37 GB.
IC est., transcoded size, ratio (e.g. first derivate)
4,62 GB -> 4,13 GB : 0.894
4,80 GB -> 4,48 GB : 0.933
4,74 GB -> 4,20 GB : 0.866
4.77 GB -> 4.41 GB : 0.925
4.76 GB -> 4.36 GB : 0.916
If the relation would be a linear function, I should have found the right value in the second step. Given the reasonable close starting value and the error margin of 0,25% I should have found the right value in three (or at most four) steps for any continuous differentiable function. Because of the jump in the ratio shown between the two blue/red lines, this fails.
I guess, this is caused by the very nature of the quantisation tables that IC manipulates.
Alas, but at least the function seems still monotonous, so you can use binary search. I usually use a starting value between 4,6 GB and 4,7 GB (thick thumb) and do not care for a little undershot and re-transcode somes extras for a overshot.
Update:
I now have found a title set the even breaks monotony (Spiderman RC2 disk1, titles 25 and 26, VTS_04). Here we have the phenomenon that smaller values at the IC slider result in larger output files. I guess this due to unusal quantisation in title 25, which also gives a "list index out of bounds" for small percentages in IC7.
Update2:
Tho "root of evil" on Spidey is in fact title 25. It gives a very funny zig-zag-curve if you move the slider in the range of 45% to 50%. Below 45% it gives the "list index out of bounds" error.
MackemX
24th February 2003, 19:50
Originally posted by schlaufer
Movie: 3,65 GB , 2x577 MB AC3 Audio
4.58-4.60Gb for that :D
schlaufer
24th February 2003, 20:16
Originally posted by MisterX
4.58-4.60Gb for that :D
Didn't you read the numbers in my post? 4.62 GB gives about 240 MB undershot. Please read the whole post before your reply.
I think I have to state the essence of post in clearer words for the mathematical uneducated: your approach (i.e. the 8% rule) is absolutely worthless because it is based on totally wrong assumptions. Those of you who remember their high school math can find a more complete argument in my previous post.
Cheers,
schlaufer
MackemX
24th February 2003, 20:37
surely you realised I was kidding, how can I make an accurate presumption on just those 2 figures using my method :D
just one thing I'd like to point out the is that the audio files are a constant within the IC est and transcoded totals therefore should not be be included in your calculations
as are the Titles still at 100%, so they need to be subtracted from the two totals so what you are left with is the beginning transcoded MOVIE ONLY filesize and the resulting file size
I haven't got enough data myself to work it out as I have only done 3 so far
but I will get there :D
but it's shame you gotta be a bit harsh in that last post, but I will not reply in the same manner, only point out I think you are wrong including the audio & 100% Titles in your calculations
cheers mate
p.s. obviously you have some sort of higher education and think riff raff like uz can't do sumz :D
p.p.s. no apology needed
MackemX
24th February 2003, 21:02
Originally posted by schlaufer
Didn't you read the numbers in my post? 4.62 GB gives about 240 MB undershot. Please read the whole post before your reply.
I think I have to state the essence of post in clearer words for the mathematical uneducated: your approach (i.e. the 8% rule) is absolutely worthless because it is based on totally wrong assumptions. Those of you who remember their high school math can find a more complete argument in my previous post.
Cheers,
schlaufer in fact reading your posts again, just shows how much of a (restrained mouth) when it comes to you thinking someone else's theories are wrong
If I thought someone's suggestions were wrong I would do one of the following
1. not try them but say it may not be correct in a polite manner without using bold and resorting to insulting their intelligence,if I felt it was incorrect no. 4 in rules (http://forum.doom9.org/forum-rules.htm)
2. try them just in case then show my incorrect results
3. say nowt at all
cheers again :D
schlaufer
24th February 2003, 21:12
Originally posted by MisterX
but it's shame you gotta be a bit harsh in that last post, but I will not reply in the same manner, only point out I think you are wrong including the audio & 100% Titles in your calculations
cheers mate
p.s. obviously you have some sort of higher education and think riff raff like uz can't do sumz :D
First of all: Begging your pardon for being harsh, no insult was ment. My intention was to emphasise the results of my mathematical analysis. I do not think bad of anyone who does not a proper analysis of the subjects he discusses - I am used to that. Mathematical education is underestimated by most computer professionals, because rather simple linear math is good enough in more than 90% of all cases. So most people forget to check their assumptions from time to time. The only thing I was a bit angry about was the fact, that I had the impression that you had just applied your (linear) formula to the movie I have given and stated your numbers without reading my post. In fact I could not see any relation between your numbers and my argument.
I try to put again a bit clearer (and hopefully in a more polite manner): To compensate for the undershoot by 8% overshoot is a rule of thumb backed up by some linear calculations on a non-linear problem. It is as good (or as bad) like starting with a fixed size based on experience. We should not put further energy in refining these formulas, because we will allways need try and error to get the right values.
Once again my apologies, I easyliy get embarassed by (seamingly) rash replies. And as english is not my mother tongue I often miss the tune in such occassions.
And finally, yes the movie was really that small. In fact the 4.80 GB size was the largest number below 100% I could enter via the IC7.0 slider.
MackemX
24th February 2003, 21:48
yes your method is correct in what you say and I think it will help me towards getting at least a margin of error from 0.05Gb
if using CCE, you would not include the audio/subs/files not transcoded would you?
you would only use the relevant movie filesize, and the space allocated for the resulting file to work out the bitrate settings
from this you could then work out the margin of error and CCE is pretty darn close when it comes to predicting so why bother :)
now obviously IC is not as accurate and thats what I'm trying to compensate for and so far it's been very close
sound files are irrelevant as are files set to 100% as they are constant throughout, the remaining files, menus are included if transcoded, then need the following data recorded individually for each relevant title :
1.every menu/title filesize (some titles are linked)
2.what size IC predicts it to be
3.the % setting
4.the resulting filesize after trancoding as shown in IC again
5.the total of titles removed (nickel feels that this affects the total also)
(Gb are't accurate enough but can be compensated by removing 0.009Gb, but if you move the slider in increments of 0.1% using arrow keys you can see whether it is a high or a low third decimal place)
the more data I get the more a pattern will probably emerge but as of now I think it is 7.25%-7.75% of the MOVIE ONLY size to add to the predicted overall total including sound
but even this will not be accurate enough but it seems strange that with a little calculations my 3 examples above have only wasted
9MB on BTTF1
61MB on BTTF2
38MB on Simpsons Disc 2making a total of 108 MB between 3 discs
and the prediction I made for EjectButton was only 0.02Gb over due to me suggesting % instead of what to add to the overall predicted filesize
now getting a result of 4.34Gb(36MB wasted) on my 3 discs and only going 0.02GB(20-29MB) over on Ejectbuttons is not purely guess work
there is obviously some sort of relation and the more data I get the closer to that I will come
EjectButton
24th February 2003, 22:06
I'm not really bothered by the result coming out 3.9 GB since I just told it to truncate the data when I burned it, so it cut off the last couple seconds of the credits on the last video track, so powerdvd will stop playing if you sit there and watch the credits all the way through, and windvd will just throw you back to the menu, beyond that everything plays fine (though I don't know what happens if you play a truncated disc in a non-pc player since I don't have one, but whatever).
as far as my interpretation that IC got less inaccurate % wise as the size of the source data increased, I did disc1 side2 of "world at war" last night and this assumption seems to be wrong, everything I had seen up to that point had led me to believe it was getting less incorrect as the size increased but this last transcode broke the trend.
video_ts size: 7.50 GB
IC target size: 4.55
resulting size: 4.25
relative size: 93.41%
ripped- (18k video track), (menu size 221mb > 84.14mb), (audio 351mb), (video is 4 connected tracks, 6.85gb total), (bar set at 58.83%)
so this disc was very similar to the previous disc, 4 video chapters, no audio or subs ripped, a very small video track ripped, but the result was 93.41% of the target for this 7.50 disc when it was 95.43% for a 7.33 disc with a target of 4.60 so I guess I don't know what to think.
MackemX
24th February 2003, 22:44
Hi Ejectbuton
firstly can I mention, that you would not include the audio/titles not selected/titles left@100% in your calculations (don't mean to upset you in way ;))
look at it this way
if you were using DVD2One or CCE, you have a target of 4.7Gb (4889MB), now if the extras & audio selected were say 904MB that would leave only 3.5Gb (3584MB) for the resulting video files and thats what DVD2One would produce automatically if allocated 904MB, or if using CCE you would allocate it manually
now in relation to IC if you can only allocate 3.5Gb to the total of the titles you have selected to keep then you need to know what the original video size is in realtion to the titles you have selected
e.g the total of the menu & title video files is 4.8Gb(4915MB) of movie, so I'm asking IC to fit 4.8Gb into 3.5Gb but to compliacte matters I am setting different % for each title
but if you write down the figures as shown above then you can not only relate what IC does to compress 4.8Gb into 3.5Gb and how accurate it is but also compare individual titles and the relevance of the % setting
there is a bit more invloved but if all the data is present then I cannot see why not you could predict the total outcome within a margin of error +- 0.03Gb
phew!
still with me? , I just wish someone would say 'Bloomin eck!, now I know what he's on about!'
cheers
if you would like to add some data to my collection please feel free to do so as it would be greatly appreciated
but I am now recording results in a spreadsheet
EjectButton
25th February 2003, 05:47
here is another example
cowboy bebop d2
video_ts 7.40gb
menu minimum 30% (161mb > 65.39mb)
5 video tracks - all 72.05% (1.33gb 1.33gb 1.32gb 1.15gb 1.16gb)
audio included (35.63mb 35.52mb 35.60mb 35.44mb 35.26mb)
audio removed (35.63mb 35.52mb 35.60mb 35.44mb 35.26mb)
english subs on
no subs removed
target 4.85gb
output 4.38gb
output vs target ratio- 90.31%
MackemX
25th February 2003, 16:26
you gotta pm Ejectbutton :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.