2nd image shorter than CD size (It shouldn't)

[r6d2]

I know the subject may look familiar, but the problem perhaps isn't. I have searched for the topic in this forum, but I have only found something similar in TMPGEnc CQ, for reasons well known, and in DivX5.

I am encoding "K19: The Widowmaker" to 2 CDs. I am using DVD2SVCD with TMPGEnc, using VBR 2 pass mode.

I end up with a first image of 816-MB (I am using 810-MB CD size, which gives a minute or so of overburn), and a second one of only 514-MB.

The video bitrate DVD2SVCD calculates (and uses) is 1546 (about the same FitCD/Moviestacker calculate, anyway). However, besides getting a shorter second image, Bitrate Viewer reports only 1208 kbps average on the final MPG file, and with relatively low quantization:


Bitrate: Peak=2720, Avg=1208
Q.Level: Peak=8.87, Avg=1.61


I have read that some movies are "maxed out" or "saturated", which shows up in DivX5 and GKnot. I have also read reports of this happenning with CQ mode due to bad prediction.

However, I had not seen this with VBR encoding and TMPGEnc.

I understand that DVD2SVCD tries to fill the CDs to its edges, except when total BR is higher that the allowed by SVCD spec and then obviously the last image is shorter. I do not know why in this case it is not working.

This is the first time this happens to me. I have encoded a couple of dozen movies, all VBR 2 Pass. I hope some of you might help.

Just in case, here are the pertainings files:

dvd2svcd_log.txt

WNASPI32.DLL 4.71.2.0
--------------------------------------------------------
- 05/06/2003 2:23:16
- DVD to SVCD Conversion
- DVD2SVCD ver. 1.1.3 build 2
--------------------------------------------------------
Initializing
Initializing finished.

--------------------------------------------------------
- 05/06/2003 2:23:20
- DVD2AVI
--------------------------------------------------------
Creating DVD2AVI INI file:
- C:\Archivos de programa\DVD2SVCD\DVD2AVI\DVD2AVI.INI

Variable settings:
iDCT_Algorithm: 32-bit SSE MMX

Executing DVD2AVI.
Executing DVD2AVI. Commandline:
"C:\Archivos de programa\DVD2SVCD\DVD2AVI\DVD2AVI.exe" -CS=2 -YR=1
-EXIT -OF=[D:\Movies\KXIX\Source\DVD2AVI_Project_file] -IF=[D:\Movies\KXIX\Source\VTS_04_1.vob,D:\Movies\KXIX\Source\VTS_04_2.vob
,D:\Movies\KXIX\Source\VTS_04_3.vob,D:\Movies\KXIX\Source\VTS_04_4.vob
,D:\Movies\KXIX\Source\VTS_04_5.vob,D:\Movies\KXIX\Source\VTS_04_6.vob
]
Analyzing DVD2AVI Project file
Force Film activated!
Framerate: 23976
DVD2AVI processing done.

--------------------------------------------------------
- 05/06/2003 2:29:55
- Free on drive D: 5505.73 mb
- AUDIO Extraction
--------------------------------------------------------
Found AC3 stream id: 0x81
Filename: D:\Movies\KXIX\Audio\Extracted_audio_1.ac3
Audio1 delay: 0 ms
Audio extraction finished.

--------------------------------------------------------
- 05/06/2003 2:38:46
- Free on drive D: 14652.46 mb
- AUDIO conversion
--------------------------------------------------------

Encoding Audio. Filename: D:\Movies\KXIX\Audio\Extracted_audio_1.ac3
Executing BeSweet. Commandline:
"C:\Archivos de programa\DVD2SVCD\BeSweet\BeSweet.exe" -core(
-input "D:\Movies\KXIX\Audio\Extracted_audio_1.ac3" -output "D:\Movies\KXIX\Audio\Encoded_audio_1.mp2" -logfile "D:\Movies\KXIX\Audio\Encoded_audio_1.log" )
-azid( -L -3db -c normal -s surround -g max ) -2lame( -e -b 160 -m s )
Audio conversion of D:\Movies\KXIX\Audio\Extracted_audio_1.ac3 finished.

Audio conversion finished.

--------------------------------------------------------
- 05/06/2003 3:07:30
- Free on drive D: 17361.40 mb
- Converting Pictures
--------------------------------------------------------
Converting: C:\Archivos de programa\DVD2SVCD\cover52.jpg
Converting: C:\Archivos de programa\DVD2SVCD\DefaultChangeCD.bmp
Converting: C:\Archivos de programa\DVD2SVCD\DefaultLastCD.bmp
Finished converting pictures
--------------------------------------------------------
- 05/06/2003 3:07:42
- Free on drive D: 17360.24 mb
- Video Encoding using TMPGEnc
--------------------------------------------------------
- Encoding D:\Movies\KXIX\Video\TitlePicture.bmp.avs
Executing TMPGEnc. Commandline:
"D:\Win\TMPGEnc Plus\TMPGEnc.exe" "D:\Movies\KXIX\Video\TMPGEnc_Project_file.tpr" /Encode /Close
Video Encoding finished.

- Encoding D:\Movies\KXIX\Video\ChangeCDPicture.bmp.avs
Executing TMPGEnc. Commandline:
"D:\Win\TMPGEnc Plus\TMPGEnc.exe" "D:\Movies\KXIX\Video\TMPGEnc_Project_file.tpr" /Encode /Close
Video Encoding finished.

- Encoding D:\Movies\KXIX\Video\LastCDPicture.bmp.avs
Executing TMPGEnc. Commandline:
"D:\Win\TMPGEnc Plus\TMPGEnc.exe" "D:\Movies\KXIX\Video\TMPGEnc_Project_file.tpr" /Encode /Close
Video Encoding finished.

- Encoding D:\Movies\KXIX\Video\AviSynth_Script_file.avs
StreamSectors: 1684607176
AudioSectors: 157613680
VideoPAPO: 23653944
ScanOffsetBytes: 0
SeqAligningBytes: 0
DVDBytes: 0
VideoEndHeader: 8
SubtitleSectors: 0
EmptySectors: 238.00
PictureSectors: 900.00
PureMPEGStream: 1503339544.00
Seconds: 7775.51
CalcMPEGStream: 1503339544.00
Frames: 186066
CDSize: 810.00
Number of CDs: 2
Cut point 805.00
Executing TMPGEnc. Commandline:
"D:\Win\TMPGEnc Plus\TMPGEnc.exe" "D:\Movies\KXIX\Video\TMPGEnc_Project_file.tpr" /Encode /Close
Video Encoding finished.

--------------------------------------------------------
- 05/06/2003 10:52:11
- Free on drive D: 16218.76 mb
- Converting Pictures from ES to PS
--------------------------------------------------------
Saving bbMPEG settings: C:\Archivos de programa\DVD2SVCD\bbMPEG\default.ini

Executing RunbbMPEG. Commandline:
"C:\Archivos de programa\DVD2SVCD\bbMPEG\RunbbMPEG.exe" "D:\Movies\KXIX\Video\TitlePicture.bmp.mpg"
--------------------------------------------------------
- 05/06/2003 10:52:15
- Free on drive D: 16218.73 mb
- Converting Pictures from ES to PS
--------------------------------------------------------
Saving bbMPEG settings: C:\Archivos de programa\DVD2SVCD\bbMPEG\default.ini

Executing RunbbMPEG. Commandline:
"C:\Archivos de programa\DVD2SVCD\bbMPEG\RunbbMPEG.exe" "D:\Movies\KXIX\Video\ChangeCDPicture.bmp.mpg"
--------------------------------------------------------
- 05/06/2003 10:52:20
- Free on drive D: 16218.70 mb
- Converting Pictures from ES to PS
--------------------------------------------------------
Saving bbMPEG settings: C:\Archivos de programa\DVD2SVCD\bbMPEG\default.ini

Executing RunbbMPEG. Commandline:
"C:\Archivos de programa\DVD2SVCD\bbMPEG\RunbbMPEG.exe" "D:\Movies\KXIX\Video\LastCDPicture.bmp.mpg"
--------------------------------------------------------
- 05/06/2003 10:52:24
- Free on drive D: 16218.67 mb
- Multiplexing and cutting
--------------------------------------------------------
Saving bbMPEG settings: C:\Archivos de programa\DVD2SVCD\bbMPEG\default.ini
Offset in Seconds: 2
Executing bbMPEG.
Variable Settings:
Movie offset: 2 seconds
Cut point: 805 mb

Executing RunbbMPEG. Commandline:
"C:\Archivos de programa\DVD2SVCD\bbMPEG\RunbbMPEG.exe" "D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File.mpg"
Length of D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File00.mpg
4775 Seconds
Offset in Seconds: 4777
Executing bbMPEG.
Variable Settings:
Movie offset: 2 seconds
Cut point: 805 mb

Executing RunbbMPEG. Commandline:
"C:\Archivos de programa\DVD2SVCD\bbMPEG\RunbbMPEG.exe" "D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File.mpg"
Multiplexing and cutting finished.

--------------------------------------------------------
- 05/06/2003 11:03:16
- Free on drive D: 14906.89 mb
- Determining length of audio
--------------------------------------------------------
Analyzing: D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File00.mpg
4785.600 seconds D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File00.mpg
Analyzing: D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File01.mpg
2982.624 seconds D:\Movies\KXIX\Muxed\bbMPEG_Muxed_File01.mpg
Analyzing finished.

--------------------------------------------------------
- 05/06/2003 11:05:32
- Free on drive D: 14907.37 mb
- Creating CD-Images using VCDXBuild
--------------------------------------------------------
- No. of chapters to create: 10

CD image #1: CD_Image_File_CD1.bin

Executing VCDXBuild. Commandline:
"C:\Archivos de programa\DVD2SVCD\D2SCCD\d2sccd.exe" --verbose --cue-file="D:\Movies\KXIX\CD_Image_File_CD1.cue" --bin-file="D:\Movies\KXIX\CD_Image_File_CD1.bin" "D:\Movies\KXIX\VCDXBU~1.XML"
--------------------------------------------------------
- 05/06/2003 11:09:36
- Free on drive D: 14895.57 mb
- Creating CD-Images using VCDXBuild
--------------------------------------------------------
- No. of chapters to create: 6

CD image #2: CD_Image_File_CD2.bin

Executing VCDXBuild. Commandline:
"C:\Archivos de programa\DVD2SVCD\D2SCCD\d2sccd.exe" --verbose --cue-file="D:\Movies\KXIX\CD_Image_File_CD2.cue" --bin-file="D:\Movies\KXIX\CD_Image_File_CD2.bin" "D:\Movies\KXIX\VCDXBU~2.XML"
CD-Image creation finished.

--------------------------------------------------------
- 05/06/2003 11:11:52
- Free on drive D: 14888.27 mb
- SVCD Creation finished!
--------------------------------------------------------
--------------------------------------------------------
- 05/06/2003 13:14:00
- DVD to SVCD Conversion
- DVD2SVCD ver. 1.1.3 build 2
--------------------------------------------------------
Initializing
Initializing finished.

Avisynth_Script_file.avs

LoadPlugin("C:\ARCHIV~1\DVD2SVCD\AVISYN~1\Mpeg2dec\mpeg2dec.dll")
mpeg2source("D:\Movies\KXIX\Source\DVD2AV~1.D2V")
# -= AviSynth script by FitCD v1.1.2 =-
BicubicResize(448,288,0,0.6,38,54,644,368)
AddBorders(16,96,16,96)

[eugen]

I have had the same problems, not so big diference (800 vs 500), but every time the CD2 was smaller than CD1. I have close the issue for me in very simple way. If I feel that SVCD needs more that 1 CD I use IFOedit to split DVD into 2 DVDs (trying to make the length of both parts equal) - and encode each part separately. It takes less time for one CD. F.i. if each part is converted for 5 hours - for me it is more convenient to spend 2 days pro 5 hours than to do it one day but 10 hours PC on.

[r6d2]

Eugen,

Good workaround. The point is that being DVD2SVCD such a great program, which automates absolutely all the needed stuff, begining to tweak and "craft" every encode results in an oximoron.

So, it seems we are stuck, because no one of the founding fathers of this forum has come to earth to give as a hint.

(Either we are on a very, very stupid situation here which we do not realise, or the problem is a real problem and everybody is clueless about a solution).

Regards,

[gerti67]

Hi r6d2,

just saw your problem report now.

You know, this sometimes happens. Seems this special movie compresses very well and so TMPGEnc doesn't feel like spending more bits here or there as it is very satisfied with it. ;)

As you can see, you got an overall average quantization factor of 1.6 - this is really good - the lower this factor, the better the picture quality has to be considered as low quantization meens not much loss of detail due to quantization (you know the lossy part in MPEG compression). It just seems - though I don't know exactly, only Tsunami can - TMPGEnc can't give more bitrate to action parts to not exceed the SVCD specs boundaries and it doesn't feel to spent a little more to other parts of the movie as they already have a very low quantization and wouldn't gain much more quality - hence the not fully used CD and bitrate.

But if you want to have a fully filled second CD - try to enable the "padding" option in TMPGEnc it will artificially fill up the bitrate with "dummy" packets and your CD should be fully filled in the end. But again, you will surely not gain more quality with it - just a happier feeling. :D Same should happen if you give TMPG a higher bitrate to play with. As long as the other parameters .e.g the destination dimensions (480x480 SVCD) stays the same - though I am not 100% sure about it and I'm possibly about talking complete nonsense here. ;)

Or, try to use CCE to see if it can do better at this special movie - at least to check my theory - or just to please me or yourself or whomever. :D

HTH,
Gerti

[r6d2]

Hi Gerti,

Originally posted by gerti67
Hi r6d2,

just saw your problem report now.

You know, this sometimes happens. Seems this special movie compresses very well and so TMPGEnc doesn't feel like spending more bits here or there as it is very satisfied with it. ;)

Thank you very much for your response. Interesting fact indeed. I had conducted a compressibility test for this movie to see if it fitted on 2 CDs and my results were satisfactory. About the same time I was encoding "The Sum of all Fears", only 12 minutes shorter, and both gave about the same compressibility indicator. However, DVD2SVCD (TMPGEnc, actually) did not have a problem with filling the 2 CDs on the latter case.

As you can see, you got an overall average quantization factor of 1.6 - this is really good - the lower this factor, the better the picture quality has to be considered as low quantization meens not much loss of detail due to quantization (you know the lossy part in MPEG compression).

You know, I was under the same impression, that Bitrate Viewer's lower Avg Q. indicated less loss of detail and therefore better quality.

However, I happened to find a thread in www.kvcd.net where they compare side by side CQ and VBR, and the "subjective" picture quality almost anyone agrees is far better with CQ at the same BR, even though if you analyse the streams with BR Viewer you get a much higher Q level with CQ!

I had to surrender before the evidence. Maybe that and therefore must not be taken for granted.

No one at that forum would give an explanation for this, they just said that you have to take Q with a grain of salt.

Perhaps the explanation is that you can't compare apple and pears, and that's what you are doing at comparing the Qs obtained by encoding with different methods.

What do you think?

But if you want to have a fully filled second CD - try to enable the "padding" option in TMPGEnc it will artificially fill up the bitrate with "dummy" packets and your CD should be fully filled in the end. But again, you will surely not gain more quality with it - just a happier feeling. :D

Yeah, instead of zeros at the end I would be spreading them along the movie... :)

Same should happen if you give TMPG a higher bitrate to play with. As long as the other parameters .e.g the destination dimensions (480x480 SVCD) stays the same - though I am not 100% sure about it and I'm possibly about talking complete nonsense here. ;)

Perhaps if I increase the resolution to 528x480... TMPGEnc would need to fit more data in there, and the picture also would be sharper.

I'll try, just to please you ;)

Thanks a lot again.

[DDogg]

If you have CCE, please also try using Tylo's plugin and the CCE one pass vbr mode for comparison. I found them equal on just a cursory inspection. I think many would appreciate hearing your opinion.

[Zoomie]

Is the file size too small with just the image or is it as far back as the mpeg file. If it's just the image, then check out the thread below. I have had similar problems with some projects but the fix is pretty easy and not very time consuming. I never found out what caused it though.


http://forum.doom9.org/showthread.php?s=&threadid=51311

[r6d2]

@Zoomie
It is not just the image but also the MPG file. I checked. Here you are the corresponing lines on the VCDXBuilder_log:


INFO: finished ok, image created with 363901 sectors [80:52.01]
INFO: finished ok, image created with 229353 sectors [50:58.03]


@DDogg,

I have CCE 2.50, demo version. I have tried Tylo's plugin with great results, although not in this movie. It is so fast that I will do that next. For now hours are still counting on the higher res test, 2 Pass VBR TMPGEnc.

[r6d2]

I finished the test with the increased res (528x480), the two images are 816-MB and 812-MB!

Bitrate viewer says:

Bitrate: Peak=2810, Avg=1519
Q.Level: Peak=12.04, Avg=0.98


Increasing the resolution not only fixed the image size, but almost halved the Q level!

[gerti67]

Hi r6d2,

thanx for pleasing me. ;)

Now back to your quantization problem. You know, quantization in MPEG encoding is a "multi-headed beast" very difficult to come by. I did a little bash reading of this monster thread over there at kvcd.net and I'm still a little bit amused how much time they spent on those settings. ;)

Let me first tell you, that the quantization level of a clip is just a mere indicator of it's quality - there's just so much more involved in getting good quality than only quantization factors (e.g. bitrate, good motion estimation, good bitrate allocation, pre-processing, ...).

Secondly, I don't trust BitrateViewer any further than I can throw away a CD with this program on it. ;) You know, though I didn't fully checked this, I think BitrateViewer is only reporting the "Quantizer_Scale_Code" (QSC) and not the corresponding quantization level - see this table for more details:
| Quantiser_Scale
QSC | Linear | Non-Linear
-------------------------
0 | (forbidden)
1 | 2 | 1
2 | 4 | 2
3 | 6 | 3
4 | 8 | 4
5 | 10 | 5
6 | 12 | 6
7 | 14 | 7
8 | 16 | 8
9 | 18 | 10
10 | 20 | 12
11 | 22 | 14
12 | 24 | 16
13 | 26 | 18
14 | 28 | 20
15 | 30 | 22
16 | 32 | 24
17 | 34 | 28
18 | 36 | 32
19 | 38 | 36
20 | 40 | 40
21 | 42 | 44
22 | 44 | 48
23 | 46 | 52
24 | 48 | 56
25 | 50 | 64
26 | 52 | 72
27 | 54 | 80
28 | 56 | 88
29 | 58 | 96
30 | 60 | 104
31 | 62 | 112
Within the MPEG stream only the QSC (column 1) values (0-31) are stored not the real Quantizer_Scale (columns 2-3). The encoder translates these QSCs internally because it knows which type of quantization is/was used during encoding (linear or non-linear quantization) - but BitrateViewer is only reporting the QSC values.

Without using this translation table this is pretty useless. :rolleyes: Why do I think BitrateViewer is acting this way? Because in the past I did quite a few encodes with CCE and played with the linear and non-linear quantization encoding option but I did not with TMPGEnc - so I don't know which type it uses. And I was always very surprised why the hell a linear encode of some chapters of a movie gave me lower Q levels and the non-linear one had much higher Q levels - for sure those test clips were encoded the exact same way only this single parameter was changed. But from what I read about MPGE encoding theory the non-linear quantization option should be used for MPEG2 encoding and it should give the encoder a more flexible way to use quantization as with the linear type.

Example: if BitrateViewer reports a QSC of 5 then this just says nothing at all - only if you know what quantization type has been used you can interpret this value - so for a linear type a real quantization factor of 10 has been used. But if the encoder wanted to use a real quantization factor of 10 with a non-linear type then he would have to encode a QSC of 9 into the bitstream. So you see that in the end both macroblocks for example were quantized with a real factor of 10 and so should be of the same quality, BitrateViewer will tell you that the linear one has a Q level of 5 and the non-linear one only has a "poor" one of 9. ;) Hmm.

Also the most important thing in MPEG compression is the encoder "tactics" - it's intelligence. He has to make fully use of all allowed methods and tricks of the MPEG syntax and options to get the best quality out of a clip. And therefore Encoders offers different approaches of encoding. Each type will internally switch to a different tatctic. These tactics are derived from experience and theory and have to be optimized for a certain scenario. So with getting an encoder into a scenario it wasn't designed for - it's like throwing Kasparow into an opening he has never seen in his whole life. He can do god-like-well but he can also use his wrong tactics and will terribly fail. And so can TMPGEnc behave when using CQ mode or Automatic VBR CQ.

See those BitrateViewer graphs on the first pages of this KVCD thread. You will see that in the VBR CQ mode the encoder tries to keep the bitrate straight and wildly varies the quantization to reach some compression. At CQ mode it tries the other way round - keep quantization straight and vary the bitrate a bit more to reach some sort of a desired filesize. And, do we really have to talk about statistics and such things like the "average"? Calculate the average of this numbers: "1-2-8-7-2" and "5-4-5-6-5". On is "4" and the second one is "5". The first row (if thought of quantization levels) can possibly reveal "bad blocks" at certain scenes, where the second row will not. Just to speak about averages. ;)

But as I said earlier - which method is better depends not only on the source material but also on the facts if the encoder can play in well-known terrain - means doing up-to-the-specs encodes - with standard dimensions and matrices and such things as the developpers usually use those settings for testing and optimizing their tactics.

For this reason one should use the encoders the way they were designed for - this clearly leads to the conclusion why I don't spend my time on things like A(S)VCD/M(S)VCD/K(S)VCDs or whatever they call it. ;)

Hope it is a bit clearer now, why sometimes the encoders just don't get it. ;)

Greetz,
Gerti

P.S. What the hell is this resolution (528x480) used for - this is not to the specs - does your standalone play this?

[r6d2]

Originally posted by gerti67
Hi r6d2,

thanx for pleasing me. ;)


You're welcome!

For this reason one should use the encoders the way they were designed for - this clearly leads to the conclusion why I don't spend my time on things like A(S)VCD/M(S)VCD/K(S)VCDs or whatever they call it. ;)

Does this mean that we should stick to VBR 2 Pass in TMPGEnc or it still depends on the material? Actually CQ has given me some satisfactions too. Which is the opening Kasparov TMPGEnc would feel comfortable with?

Hope it is a bit clearer now, why sometimes the encoders just don't get it. ;)

A lot, a lot clearer. Thank you very much.
About averages, i don't use them anyway. I save the "seconds" file to Excel and plot moving averages. The trends show up very clearly. I also compute correlations, least squares, etc., to make a decision (you know, some times you just cannot avoid being an engineer :D )
Of course this is rather useless if data does not represent a "true" real magnitude.
I have also found that Bitrate Viewer does not deliver the same output on differents runs with the same input. Interesting, eh? It is somewhat non-deterministic then.
Do you know about a tool that might give better objective indicators than Bitrate Viewer?

P.S. What the hell is this resolution (528x480) used for - this is not to the specs - does your standalone play this? [/B]
You know, my house was robbed 6 months ago and I was ripped my good brand DVD player. I was also out of budget, so now I have this very cheap new DVD player branded Bluesky. Its price in my country is about half of mainstream brand players. It is made in China.
Surprisingly, this wonderfull device plays almost every single weird out-of spec thing I've tried. I know that not to abide by the standards may render my SVCDs useless some day, when my player ends its useful life. But I don't think DVD player development will become more restrictive. On the contrary, 2 years ago they were much more limited than today, and more "rule enforcers" than today.
(However, it does not play selectable subtitles, which is a feature I wanted badly.)
These chinese people are beginning to rule, guys... I don't know about other places, but here at least, you can find anything chinese made stuff half the price mainstream brands.
Regards,

[kwag]

Originally posted by gerti67


For this reason one should use the encoders the way they were designed for - this clearly leads to the conclusion why I don't spend my time on things like A(S)VCD/M(S)VCD/K(S)VCDs or whatever they call it. ;)



Hi Gerti,

Maybe these are some of the reason why we spend so much time with KVCD methods :D

www.kvcd.net/704x480-showoff.mpg
www.kvcd.net/small-adaptive-sampler.mpg
www.kvcd.net/red-planed-action-704x480.mpg
www.kvcd.net/red-planet-704x480.mpg
www.kvcd.net/red-planet-extreme-704x480.mpg

AviSynth script (Dynamic Linear Adaptive filtering + Scene Change Detection) here: http://www.kvcd.net/forum/viewtopic.php?t=3483
And main thread and discussion here: http://www.kvcd.net/forum/viewtopic.php?t=3999

Edit:
All samples are the way the complete movie looks like on ONE CD-R.
Don't try that with CCE or TMPEG's 2-pass mode!

Regards ;)
-kwag

[gerti67]

Originally posted by r6d2
...
Does this mean that we should stick to VBR 2 Pass in TMPGEnc or it still depends on the material? Actually CQ has given me some satisfactions too. Which is the opening Kasparov TMPGEnc would feel comfortable with?
...
Do you know about a tool that might give better objective indicators than Bitrate Viewer?
Nope, it means, you shouldn't try to restrict TMPGEnc when using the CQ mode - in clear words, dont't try to force him to get a desired filesize or force him to use some unusual matrices and/or "perverted" GOP structures. I know, this is a good topic to argue but I won't.

For some testing software - you know it is very difficult to objectively compare video sequences - the German c't magazine uses a software called JNDmetrix-IQ from Sarnoff - it measures picture quality compared to the original with a "human visual system" derived from extensive tests of human eyes behaviour on judgeing picture quality.

(http://www.sarnoff.com/products_services/video_vision/jndmetrix/documents/JND_whitepaper_0106.pdf)

Now to kwag. ;) - Why is it, I knew, sooner or later you would step in here? ;)

Originally posted by r6d2
...All samples are the way the complete movie looks like on ONE CD-R.
Don't try that with CCE or TMPEG's 2-pass mode!...
Might be true - but it's "well chosen" material - dark scenes, with motion but dark - an encoders delight. ;) And it's NTSC stuff - PAL needs more bitrate - I live in PAL land so ... no go! Also, it is all in all heavily blurred and smoothed up - not to my taste. I'm not satisified with it - but beauty is in the eye of the beholder so do whatever you want to do and spend your time on experiments and encoding sessions - I will just take 1 minute stand up and change the SVCD in my standalone after getting my a cool beer from the fridge. :D

Greetz,
Gerti

[DDogg]

Gerti, I look at Kwag's and groups work a little differently. Like you, I don't mind burning an extra disk, especially since I have a 3 disk player. What I do like about it is the work they are doing to use the new features of Avisynth 2.5x to apply conditional filters based upon a measured criteria. I would imagine they are taking a huge speed hit with some of the massive filtering they are using. For us, applying MUCH lighter conditional filtering may well be a way to bring those borderline 3 disk encodes down to a high quality 2 disk set without that over compressed look that most all of us despise.

BTW, Kwag, I do wish I could talk you into trying those scripts with 1pass CCE vbr just for a comparison. This may well bring the speed within acceptable limits. In the advanced forum I asked bach to consider doing a methodology comparison between the two methods. His stuff is always interesting so maybe you may find it so.

[kwag]

Hi DDogg,

Well I did try CCE, but remember that we mostly use MPEG-1 instead of MPEG-2. There's just no comparison, because CCE can't match the quality we get with TMPEG in MPEG-1, no matter if I encode with CCE as MPEG-1 or MPEG-2! So for MPEG-1, there's just no competition right now.
As for the filtering, you can use the current adaptive script as it is, and just lower the values if you want a lower "blur" scale. The way the adaptive script is currently set, is playing tricks on human vision. Steady scenes are not blured at all, and as motion starts to increase after a treshold, so does the blur. The eye can't really tell details on high motion anyway, so we take advantage of blur on high scenes. This also produces less blocks on high actions, because the encoder sees less sharp (or none!) edges on motion. Also, we blur heavily on the scene before a scene change, and the scene right after the scene change. Again, the human eye sees a "blink" in the scene change, but the encoder sees a softer transition, and this is saving lots of bits on a complete movie :)

@gerti67,

There's just no way any 480x480 SVCD can look like any of the 704x480 samples I provided. And I wouldn't call the www.kvcd.net/704x480-showoff.mpg sample a "dark scene", and indeed it was well picked for the "Extremely high action" of smoke, fire, etc. ;)

-kwag

[r6d2]

@DDogg,

I finished my homework. I run D2Sroba on K19. Here are the results:

2 CDs: Q=11, Avg.Brate=1511
3 CDs: Q=2, Avg.Brate=2350

I don't know how those Qs are, since I'm not used to CCE (I have not bought it and that logo sucks). But if Tylo's recommended start Q is 38 (was 32), I guess they are pretty good. Aren't they?

So, it seems that this particular movie compresses very well even on 2 CDs.

Do you agree?

I'm thinking of using D2Sroba as a general compressibility test, then use TMPGEnc for the final encode anyway.
Do you guys think the results obtained with CCE in terms of # of CDs to use can be applicable to TMPGEnc too?

Regards,