(XviD) Statsreader

[unplugged]

:confused: there is something that maybe not clear in XviD CC or alt-CC, to me and maybe others.
Does internal CC algo estimates all frames (size) just prior starting 2nd pass encode or calculates them one by one during the encoding process?
Excuse me, perhaps too stupid the question, but it's to know a bit more...
Of course, the first method that I have indicated is much less "redundant" whereas the second suffers the distorsion or difference between the linear (original) curve and the compressed curve.

With XviD when you tweak CC or alt-CC the frames sizes are scaled having the average frame size as "center of gravity" (everything close or equal to average size in 1st pass remains close to average also in 2nd pass, because of the center of gravity; much like ABR).

Koepi, do you call your last scaling method linear because it mainly divides everything with 1st-pass/2nd-pass ratio? (center of gravity for scaling is 0; much like VBR)
Maybe this was another stupid question, but again it's to know what's intended as old and new method, what's intended to be better, what's intended to be linear...

You indicate the linear method more precise with frame size distribution, If I have well understood it's because just before starting the external 2nd-pass process the *sum* of target frames' size is perfectly aligned with final requested size.

When we use a non-linear 2nd pass scaling method (like alt-CC) one strong point that we should care in the pre-encoding phase is to implement a numerical formula to draw up the *entire* frame size list to plan and start to manage the total distribution just before the encoding process:
- of course having the sum of pre-calculated frames sizes as target equivalent to requested file size
- having the underuse by excessive high curve compression (typical underuse of bits due to user param, too conservative) equally compensated in *all frames* (a sort of ABR... over impossible VBR)

I don't know at all how and when XviD decide 2nd-pass frames sizes (if on-fly frame by frame or precalculating), does alt-CC suffers by continuous up and down overflow due to lack of a total and prior precalculating phase?

I'm not a good programmer, I'm not trying to criticize or say anything. It's only to know how raw or perfect it is. ;) This is very interesting, infact I think noboby (except devs) really knows how XviD draws up CC. :)

Sorry, my few thoughts suffer very much by english exposure and my expressions often results too cumulative... :(

[Koepi]

hehe iago :)

actually, i just hacked up second pass treatment, there was no need to redo the first pass, sorry for not being clear about that :(

I'm still a little unsatisfied as i more or less disabled curve treatment for second pass while using 2nd pass external compression together with activated credits (thus resulting in only fixed quant credits work), and so any stacked-up overflow until the credits start get's carried over to the final filesize. my matrix rip is ~2mb oversized...

at least it's better than before ;)

Regards,
Koepi

[iago]

Originally posted by Koepi
hehe iago :) actually, i just hacked up second pass treatment, there was no need to redo the first pass, sorry for not being clear about that :( Yes I knew/guessed that but my previous first pass stats file was "without" lumi, so this time I did a first pass "with" lumi ;).
Originally posted by Koepi
I'm still a little unsatisfied as i more or less disabled curve treatment for second pass while using 2nd pass external compression together with activated credits (thus resulting in only fixed quant credits work), and so any stacked-up overflow until the credits start get's carried over to the final filesize. my matrix rip is ~2mb oversized... at least it's better than before ;)Same here. My Fight Club rip is ~5mb oversized but absolutely better than before, as I expected. (Now I'm producing another Ogg audio file with a lower filesize, as the only solution ;)).

best regards,
iago

[Didée]

Perhaps it´s too early in the morning for me, and my brain is still sleeping ...

I don´t see the advantage of the linear downscaling done by koepi´s statsreader:

CC/AltCC concept:
- make big frames smaller, to the benefit of small frames

Linear downscaling concept:
- make *everything* so small that it fits

I have to admit: So far, I´ve done no test with this new method (having to free up ~200 GB HD-space completely for urgent troubleshooting - no time for experiments).

But, to speak with unplugged: -> First of all the concept <-

From theory, I see that small frames are put at a disadvantage with linear downscaling - especially in addition with the encouraged "disabling" of any CC along with that.

Could someone give a short explanation *why* linear downscaling should give better results than AltCC ??
I would like to (really) understand the concept.

[unplugged]

Originally posted by Didée
CC/AltCC concept:
- make big frames smaller, to the benefit of small frames

Linear downscaling concept:
- make *everything* so small that it fits
Yes
Originally posted by Didée
But, to speak with unplugged: -> First of all the concept <-

From theory, I see that small frames are put at a disadvantage with linear downscaling - especially in addition with the encouraged "disabling" of any CC along with that.

Could someone give a short explanation *why* linear downscaling should give better results than AltCC ??
I would like to (really) understand the concept.
First, nobody has said that linear is better, mainly it has a positive point regarding the distribution, that is (more) homogenous.
Despite small frame penalization I think linear method may make better the final job only because the XviD CC is difficult to configure and may not have a good frame-distribution code for entire video (and it's difficult to setup), but who knows how XviD CC draws up 2nd-pass frame size list...

[unplugged]

First, nobody has said that linear is better, mainly it has a positive point regarding the distribution, that is (more) homogenous.
What I'm trying to mean is that linear could be sometimes better not because the concept is better than alt-CC but because the "linear" algo is very easy to implement in a homogenous way, much precise to approach the end of file without too overflow adjustments (up 1235, down 4345, up 7686, up 2000... fluctuations due to non-linear CC not well predicted).

It's what I know at this moment, maybe wrong or maybe not exact, but until nobody responds... :-|

[iago]

And here are the exact results:
(Btw, quantizers were capped 2-6/2-16 in the test.)

1stPass/2ndPass: 1.963:1
(from statsreader, aiming for 634mb (~649000kb), which came out ~654000kb in the end)
---------------------------------------------------------------------
DebugView analyzer for XviD codec v0.11 by MoonWalker
e-mail : s_ilias@gmx.net

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 7124 Times, Percentage Used : 3.63%
Quant 3 Used : 139758 Times, Percentage Used : 71.30%
Quant 4 Used : 48440 Times, Percentage Used : 24.71%
Quant 5 Used : 644 Times, Percentage Used : 0.33%
Quant 6 Used : 49 Times, Percentage Used : 0.02%
Quant 7 Used : 1 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.218

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 4188 Times.

MPEG Quantization Type Used 200204 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 14 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 3 Used : 2217 Times, Percentage Used : 90.27%
Quant 4 Used : 46 Times, Percentage Used : 1.87%
Quant 5 Used : 177 Times, Percentage Used : 7.21%

Credits
---------
Quant 31 Used : 16 Times, Percentage Used : 0.65%

Number Of Consecutive I-Frames : 149

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 7124 Times, Percentage Used : 3.60%
Quant 3 Used : 137541 Times, Percentage Used : 69.55%
Quant 4 Used : 48394 Times, Percentage Used : 24.47%
Quant 5 Used : 467 Times, Percentage Used : 0.24%
Quant 6 Used : 49 Times, Percentage Used : 0.02%
Quant 7 Used : 1 Times, Percentage Used : 0.00%

Credits
---------
Quant 31 Used : 4172 Times, Percentage Used : 2.11%


Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 2456
Number Of Inter-Frames (P-Frames) : 197748
Total Number Of Frames : 200203

1.23% of the Movie is Intra-Frames (Key-Frames)
98.77% of the Movie is Inter-Frames (P-Frames)


Size Analysis
----------------

1-Pass Size : 1305113986 Bytes or 1274525 KBytes
Scaled Size : 665049007 Bytes or 649461 KBytes
Actual Size : 665047594 Bytes or 649460 KBytes

Usefull Statistics
------------------
Compressibility : 50.96%
Relative Quality of XviD avi : 62.15%
Absolute Quality of XviD avi : 96.35%
---------------------------------------------------------------------

@unplugged
Sorry to interfere with your posts.

best wishes,
iago

[rui]

About the diference between using internal and external compression:

Internal
DebugView analyzer for XviD codec v0.11 by MoonWalker
e-mail : s_ilias@gmx.net


Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 4 Used : 126 Times, Percentage Used : 3.65%
Quant 5 Used : 568 Times, Percentage Used : 16.44%
Quant 6 Used : 1012 Times, Percentage Used : 29.29%
Quant 7 Used : 911 Times, Percentage Used : 26.37%
Quant 8 Used : 605 Times, Percentage Used : 17.51%
Quant 9 Used : 191 Times, Percentage Used : 5.53%
Quant 10 Used : 40 Times, Percentage Used : 1.16%
Quant 11 Used : 2 Times, Percentage Used : 0.06%

Average Quantizer Used for Movie : 6.592

Quantizers Used For Credits :
--------------------------------
Quant 20 Used : 115 Times.

MPEG Quantization Type Used 3570 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 26 times

External
DebugView analyzer for XviD codec v0.11 by MoonWalker
e-mail : s_ilias@gmx.net


Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 4 Used : 158 Times, Percentage Used : 4.57%
Quant 5 Used : 718 Times, Percentage Used : 20.78%
Quant 6 Used : 1071 Times, Percentage Used : 31.00%
Quant 7 Used : 863 Times, Percentage Used : 24.98%
Quant 8 Used : 505 Times, Percentage Used : 14.62%
Quant 9 Used : 126 Times, Percentage Used : 3.65%
Quant 10 Used : 12 Times, Percentage Used : 0.35%
Quant 11 Used : 2 Times, Percentage Used : 0.06%

Average Quantizer Used for Movie : 6.369

Quantizers Used For Credits :
--------------------------------
Quant 20 Used : 115 Times.

MPEG Quantization Type Used 3570 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 30 times

As you can see, there is a diference between them, being external a little better.

[iago]

@rui

Thanks for that really helpful test, which supports my (and I guess Koepi's) visual observations with some real technical data.

However, the "oversize" issue, which points to the predictability being broken, (as also explained by Koepi in his above post,) is still a problem to be solved imho. (Entering a lower filesize in the statsreader should not be the only way to go ;))

best wishes,
iago

[MoonWalker]

Hi,

I have done some test my self too and more or less I had the same results.I am doing some more now. StatsReader - CC 0/0 - AltCC Default. The only thing that I didn't like is the consecutive I-Frames.. :


Start Frame | End Frame | Number of Consecutive I-Frames
-------------+-------------+-------------------------------
195927 | 195935 | 8 Credits
196026 | 196034 | 8 Credits
196037 | 196155 | 118 Credits


I have posted only the ones in the credits portion.
My parameters were the defaults using AltCC and Koepi's latest build..I had a total of 608 consecutive I-frames.

MoonWalker

[Koepi]

If you're using altCC you have to set either strength to 0 or disable automatic min. relative quality and set it to 100. Else you don't get linear scale...

Thanks for testing!

Regards,
Koepi

[Koepi]

Hm, my hack doesn't work well:

My matrix-h263-quant-type encoding came out 8MB undersized.

Maybe we should leave credits alone...

But the quality is very nice.

Regards,
Koepi

[iago]

Originally posted by Koepi
My matrix-h263-quant-type encoding came out 8MB undersized. Maybe we should leave credits alone... So the problem is not only getting oversized files, which could simply be handled (though not being the proper way of course) by entering a bit lower filesize in statsreader. The case is total lack of predictability then.

Koepi, I have a couple of questions on mind now, the most important of which is:

When we leave the credits alone, will we still be able to get better quality with external compression and linear scaling (due to oversized credits this time), although the final file size will be accurate)?

best regards,
iago

EDIT: And one more question, which is still unclear for me:
Do you advice strength:0 (or mrq:100) only for external compression/linear scaling, or also for internal compression with default altCC parameters?

Sorry to bother you with these questions, but I'm ready to start a new test encode ;).

[Koepi]

Hi iago,

most certainly: no.

I think I have to code that properly into XviD ;)

I can live with this improper size since the quality is nice, and maybe later I'll try again to fix this stuff.

Best regards,
Koepi

[Koepi]

Hm, use those values if you want to test linear scaled curves, else the defaults should be fine. I still don't understand why the internal curve sclaing routines give another result than the external linear scaled curve though.

Regards,
Koepi

[iago]

Originally posted by Koepi
I can live with this improper size since the quality is nice, and maybe later I'll try again to fix this stuff. LOL! But "I" can't live with "this" improper size Koepi, (5mb oversized), 'cause I've reached my limits and can't create a lower size ogg audio (q.001), although the quality is very nice! :) :)

Well, OK, I'm joking of course ;).

So, as a result, we are waiting for the next harvest of your valuable efforts (which will solve this "damn" credits issue :)), when you have the time of course.

with my best regards
and many thanks for your prompt replies,
iago

PS: XCD, which could be a solution in this case, doesn't work for me due to my CD writer (Asus 32x12x40) I guess :(. Whatever program I use for burning, I always get an error message with my writer!)

[Koepi]

Since I don't know the name of your drive i can just try to help:

ftp://ftp.asuscom.de/pub/ASUSCOM/

maybe you find a newer firmware there, I don't know where the problem derives from.

Maybe you should use "force-aspi" drivers and fireburner for burning the created image :)

Best regards,
Koepi

[iago]

@Koepi,

Thanks a lot, I will try :). Also, sorry for switching off-topic in this thread.

best regards,
iago

[rui]

Well, continuing off topic :D, you can try in this site.

http://www.firmware.fr.st/

This is where i could find a firmware to my dvd reader to unlock it.

[Koepi]

Hehe, I didn't find any "asus" burner news there so i directed iago directly to the asus ftp ;)

Enough of off-topic, we ride on:

XviD-29082002-1:
- Activated EPZS(^2) motion estimation algorithm.
- Fixed quantizer mode for external compression/credits

I tried again to fix the external compression/fixed quantizer credits treatment. You have to use a fixed quant smaller than 31 to let it work, I try to vary the quantizer +/- 1 in credits to get rid of overflow or underflow. Hopefully this works, my test run will take 5 hours again...

Regards,
Koepi

[iago]

@Koepi

I'm so glad to hear this almost-immediate good news, and waiting for your test results impatiently. And one more question to bother you ;):

If this time the credits treatment works the way as you expect, will it be possible to use the first pass "quant31" stats file in the second pass? (I guess no, which means I'll do the first pass again... :))

Anyway, no matter! If this issue is solved, I'll be so glad that I can start a thousand fresh two passes happily ;).

thanks,
iago

[Koepi]

Unfortunately you can't reuse that stats file as the statsreader just leves those credits values untouched.

Some more tests should be made, with short clips and some artificial credits, maybe comparing "before"(old build) and "new"(...build).

I just did a test on the start of matrix, 1000 frames, credits from 500-1000... and ended up with a overflow which was ~2kb, instead of stacking up to some MB or just not compensating for ~1mb variation.

Regards,
Koepi

[Koepi]

Ok, now full stop again!

I'll put up a new binary soon, somehow a macroblock skip threshold was set too high, resulting in a less detailed picture.

...and again, we have to redo our first pass stats files :-(

[Koepi]

XviD-29082002-2:
- Activated EPZS(^2) motion estimation algorithm.
- Fixed macro block skip-threshold. Sorry I didn't notice before
that this was changed in CVS - my "private" builds had them
disabled so i blindly trusted they were fixed in CVS, too.
- As bonbon I added a "new modulated HQ (experimental)" mode for
modulated quantizers, Isibaar suggested that: h263 quant for <4,
mpeg quant for higher quantizers. Should eleminate some noise
from the "huge" frames, and mpeg quant seems to perform better
with high quantizers vs. blockyness than h263 quant.

Man, I'm sorry pals! (hehe, same post as on another thread ;) )

Ok, let's get to work again... first pass h263 quant started.

Regards,
Koepi

[iago]

Originally posted by Koepi

XviD-29082002-2:
- Activated EPZS(^2) motion estimation algorithm.
- Fixed macro block skip-threshold. Sorry I didn't notice before
that this was changed in CVS - my "private" builds had them
disabled so i blindly trusted they were fixed in CVS, too.
- As bonbon I added a "new modulated HQ (experimental)" mode for
modulated quantizers, Isibaar suggested that: h263 quant for <4,
mpeg quant for higher quantizers. Should eleminate some noise
from the "huge" frames, and mpeg quant seems to perform better
with high quantizers vs. blockyness than h263 quant.
So... it's time to send 18082002 and 28082002 builds to the trash together with the previous first pass stats files, install the new 29082002-2 build with the fixed macro block skip-threshold and the new bonbon, and then start new fresh two pass encodes :).

@Koepi,

Are we trying external compression stats again with fixed quantizers <31 this time? ;)

(Off-topic: Btw, my XCD image burning problem is solved now, and I can happily aim for higher filesizes from now on ;))

best wishes,
iago

[Koepi]

Cool iago,

what solved your XCD problem?

And yes, the fixed quant for ext. comp. still should be lower than 31 - I 'd suggest the default with 20 is fine... :)

Regards,
Koepi

[iago]

Off-Topic: sorry everyone...
Originally posted by Koepi
...what solved your XCD problem? Well, actually "fireburner" did ;). I realized that it had got nothing to do with firmware, and after many unsuccessful tries with nero, cdrwin and cdrdao, "fireburner" solved the problem :).

I'm a much happier man now :)
iago

[Koepi]

Ok, prime time again...

Stats reader gets even more accurate, i introduce version numbering now ;)

Version 1.1 uses KB instead of MB as downscale-size. In my tests the accuracy hits in the bounds of 100kbytes... :) (for the stats file only, the final movie has to be encoded then ;))

Thanks iago for telling me that it's the right attempt :)

Find it attached to this post.

Regards,
Koepi

[zulu]

Hi everybody!

Here is my test contribution for the 29082002 build / statsreader 1.1.
The movie i tested is "The Timemachine", runtime ~92 mins.


I made the following settings:

Neutral Bicubic Resizing (0.5) to 576x240
aimed file size: 636MB (~945 kbps)

external second pass (of course..)
min/max I quants: 2/6
min/max P quants: 2/16
"old" CC: low and high at 0, payback delay 250, payback proportionaly
alternative CC disabled
no hinted ME
credits encoded with fixed quant 20
all othere setting were set to default


Results:

The final avi was ~3MB oversized.
Can't say much in terms of visual quality - my gfx card is broken, i temporarily use an old and crappy virge card. Direct show doesn't seem to like it :(
I'll watch it on my brothers pc, tomorrow.

Here are the results of the debug analysis:


DebugView analyzer for XviD codec v0.11 by MoonWalker
e-mail : s_ilias@gmx.net


Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 71 Times, Percentage Used : 0.05%
Quant 3 Used : 56726 Times, Percentage Used : 43.53%
Quant 4 Used : 70863 Times, Percentage Used : 54.38%
Quant 5 Used : 2612 Times, Percentage Used : 2.00%
Quant 6 Used : 43 Times, Percentage Used : 0.03%

Average Quantizer Used for Movie : 3.584

Quantizers Used For Credits :
--------------------------------
Quant 20 Used : 7510 Times.
Quant 21 Used : 3 Times.

H.263 Quantization Type Used 137828 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 8 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 3 Used : 1146 Times, Percentage Used : 79.47%
Quant 4 Used : 48 Times, Percentage Used : 3.33%
Quant 5 Used : 217 Times, Percentage Used : 15.05%

Credits
---------
Quant 20 Used : 31 Times, Percentage Used : 2.15%

Number Of Consecutive I-Frames : 173

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 71 Times, Percentage Used : 0.05%
Quant 3 Used : 55580 Times, Percentage Used : 40.75%
Quant 4 Used : 70815 Times, Percentage Used : 51.92%
Quant 5 Used : 2395 Times, Percentage Used : 1.76%
Quant 6 Used : 43 Times, Percentage Used : 0.03%

Credits
---------
Quant 20 Used : 7479 Times, Percentage Used : 5.48%
Quant 21 Used : 3 Times, Percentage Used : 0.00%



Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 1442
Number Of Inter-Frames (P-Frames) : 136386
Total Number Of Frames : 137827

1.05% of the Movie is Intra-Frames (Key-Frames)
98.95% of the Movie is Inter-Frames (P-Frames)



Size Analysis
----------------

1-Pass Size : 1306169592 Bytes or 1275556 KBytes
Scaled Size : 666732921 Bytes or 651106 KBytes
Actual Size : 666733963 Bytes or 651107 KBytes

Usefull Statistics
------------------
Compressibility : 51.04%
Relative Quality of XviD avi : 55.80%
Absolute Quality of XviD avi : 95.25%

[Koepi]

Thanks for testing, zulu!

Hm. 3MB oversized. Still not good. Damn. I think I've to code harder ;)

Thanks again,

best regards,
Koepi

[zulu]

Hm. 3MB oversized. Still not good. Damn. I think I've to code harder



Harder? It's 5.30 am in göttingen! go to bed and get some sleep, man! ;)

[Koepi]

Ok, my matrix h263/h263 rip has 3 MB oversize, too.

Now my mpeg/new modulated rip is finsihed, and it's size is 2kb different from the h263 rip.

So the file size deviation seems to be systematic, but i don't know where the error derives from as the overflow is absolutely in the range where it belongs in the codec.... Let's see if I can find out.

Best regards,
Koepi

[iago]

@Koepi,

Same here with Fight Club man ;):

h.263/h.263 (29082002-3 build): ~4.5 mb oversize
MPEG/MPEG (30082002-1 build): ~4.5 mb oversize

best regards and thanks again for your ongoing efforts on solving this problem with linear scaling,
iago

[sherpya]

I've made some test without credits, now I want to try with credits...
Just 2 questions:
1) Credits into xivd codec must be disabled?
2) Into statreader, I must check credits then two options are: first start frame of credits and second the fixed quantizer, right?

I want to use h263 quant type for 1st and Mod HQ for 2nd, it's completly wrong or I can try these settings... Koepi I hope you have made this quant type to use it :D

[Koepi]

I#ve added that quant type because Isibaar had a good idea with it - it has to proove if it works out as thought...

Well. for the credits stuff:

in xvid, do the first pass with a fixed quantizer (e.g. 20) credits. Remember those values of the start and endframe for the credits.
After that's done, go to statsreader, open the stats, and check "use credits", in the first field enter the start frame, in the second the end frame.
This will have following result: statsreader doesn't scale those frames within the credits range - it's assumed the are correctly scaled already (hence the fixed quantizer stuff).

Sadly, you'll get a slightly oversized file. maybe you should take precautions like subtracting around 4 MB from your desired file size.

I've to track down where this overflow comes from, it shouldn't be there. I'll look into it when I find the time.

Regards,
Koepi

[sherpya]

Here is the results:
I've used h263/modhq
video size 1194.61->1198.1
3.5mb oversized

Options used:
Motion search precision: 6
Quant Type: h263/modhq
Credits fixed to 20
2nd pass opts:
Min I-frame: 2
Max I-frame: 6
Min P-frame: 2
Max P-frame: 16
Two Pass:
I frame boost %: 0
High bitrate scene %: 0
Low bitrate scente %: 0
playback proportionally

Video lenght 1h:41.38

The encoding was fine, some artifact but not so visible
Very small amount of blocks during high motion scenes but not visibile with postprocessing

I will try to mux into an ogm with 2 audio tracks and 2 subtitles... humm still have some problem embedding srt into ogms...

Edit: no problem with subtitles ... Now I've an ogm with 2 lang, 2 subtitles and chapiters...,
DVD Decripters does automaticatilly chapter list creation but I need to change chapter names by hand, anyone knows a software to take chapter names directly from dvd?

[Koepi]

Ok, since this is a somewhat constant error I thought about it again:

my scaling formular before was:

(1st pass size - credits size) / (desired size - credits size)

This is changed to

(1st pass size) / (desired size - credits size).

The tests I did scaled the curve to ~3.5MB less (!) than the desired size - but that's the amount it got oversized before!

Find attached statsreader 1.2, and please test if it solves the issue!

Thanks and best regards,
Koepi

[Koepi]

Originally posted by sherpya
DVD Decripters does automaticatilly chapter list creation but I need to change chapter names by hand, anyone knows a software to take chapter names directly from dvd? [/B]

The names aren't stored anywhere on the CD. They are given by a DVD menu that you needed to rip somehow. Since this is different for every DVD i don't think you'll have much luck doing that.

Regards,
Koepi

[Bluedan]

Look @ blockbuster (http://www.blockbuster.com)
Usually they have a chapter list (in english) for mostly any DVD on the market. But be aware that information given there refers to Region 1 products in general. So sometimes chapter info (for exemple: total amount of chapters!) isn't appropiate. But have a try ...with copy'n paste. I'm mostly satisfied.

[sherpya]

I will test version 1.2 for oversize problem later, main problem was splitting ogm with 2 audio 2 sub and chapters... but this is not the right forum to discuss this... sadly cutting ogm files is not easy
I've made a tricky process mux(without subs)->cut->demux(graphedit)->mux 2 splits (with subs and chapter list rearranged)
Really a nitemare...:(
OggCut really works only if ffdshow is deactivated and without subs.
I've deactivated also cladfx.ax (a filter from powerdvd???).
Btw remaining in topic video encoded with h263/modhq has some problem when viewing with ffdshow (even with use xivd and idct xvid). It shows artifatcs

[iago]

Now going for Matrix 2ndPass using external curve compression with statsreader 1.2, hoping to see that the oversize problem is finally overcome! :).

regards,
iago

[Koepi]

Hehe, thanks for testing :)

I'm looking forward to see results (and I'll test it myself, too, of course!)

Best regards,
Koepi

[sherpya]

with 1.2 600k oversize, I think it would be ok

[Koepi]

Sherpya:

YAY! I did it ;)

It's not logical for me why this solved it as it is wrong mathematics, frankly speaking, but 600kb is well in range for my taste.

Thanks!!! :)

Regards,
Koepi

...who's a little happier now...

[ookzDVD]

@Koepi,

I'm using the StatReader v1.1,
try to scaling the "We Were Soldier", from 2760Mb to 965Mb(988160Kb)
I got the negative result :(

I'll try to use your latest one v1.2,
I hope it will resolve the problem.

[Koepi]

negative result? That's odd :-/ hopefully 1.2 works for you.

Btw., you should change something in your settings, 2.7GB to not even 1GB is going to be bad quality, can't work out nicely.

My latest encode came out 1.7MB oversized again.

But I fell over a strange bahaviour of the encoding - the frames from the first pass file seem to be different as from the second pass file. I'll switch to mpeg2dec.dll and do a proper 2pass again to see if that's true.

Regards,
koepi

[Koepi]

Ok, new stats-reader (1.3) with even more precise scaling - and hopefully fixed "huge size" problems like OokzDVD ran into.

(using double instead of single precision now...)

Best regards,
Koepi

[ookzDVD]

@Koepi,

Thank you for the _fast_ response ;)
I hope it will resolve the problem.

[iago]

@Koepi

My Matrix rip with statsreader 1.2 came out only ~400kb oversized, which is quite acceptable imho ;). (mpeg2dec.dll)

regards,
iago

EDIT: And now, time to give the newborn 1.3 a try! ;)

[Koepi]

Full stop, iago ;)

I found my error:

I have to subtract the AVI overhead from the second pass desired size to get proper results, so my attempt above is flawed!!!

Here we go, StatsReader 1.4.... sorry for the massive amounts of releases!

Best regards,
Koepi