CQMatic/CalcuMatic Continued...
 

Thanks Rui :)
Thanks Phil :)

-kwag

Karl, do you envisage any problems using these programs uder WINE?

I managed to get TMPGEnc working (as per your advice of 4/1/05 in this thread http://www.kvcd.net/forum/viewtopic....378&highlight= ). It doesn't seem to be encoding the audio tho - I'll try besweet, although I'm probably lacking mp2 codecs in MPlayer I think...

Its just when I tried Calcumatic using WINE, the program terminates when I point it to a file (in this case a non-warez avi file). Also, the top 3 buttons did not appear until I clicked where they ought to be.

Sorry if this is wandering off topic.... :?

I haven't tried it :!:
But it should work. As you already have WINE installed, why not try it :D Well, you could just encode the audio with ffmpeg :idea: CalcuMatic uses DirectX to open media files. Maybe that's why it doesn't work correctly on Linux under WINE?It's fine :)

-kwag

Hi guys :),
Karl, from what I could read on mplayer's mailing lists, it is not very good to encode audio with it.
And both Mplayer and FFmpeg are based on libavcodec, right?
I wonder if toolame would work under wine?
This is getting pretty interesting, although a bit off-topic :lol:.
What other audio encoders are there that can be used under *nix, Karl?
Cheers

Wasn't tooLAME included some time ago? By the way, the author's apparently working on a new version which should fix a lot of bugs in tooLAME.

Sorry Kwag.
It's not fair to post my result, since it's my first test with CQmatic 1.4.04. But I want to post it to see if I did something wrong.
The DVD is "Los Lunnis", PAL, AR 4:3, 81 min 08 sec.
TMPGenc Plus 2.521.58.169 (just in case...)
My script is MA with triming, RemoveGrain instead UnDot, and FieldDeinterlace.
In first prediction (fast phase with 10 cycles, and 7 prediction cycles) CQ was 60,25. Final file size 698952 Kb (desired 731072 Kb, -4,4% :( ).
I run a second prediction, now CQ 63,82 ( 8O ). After encoding, final file size is 777914 Kb (+6% :cry: ).
Is this just bad luck, and in my first test I met with the worst non-linear face of TMPGenc CQ mode?, or did I anything wrong?.
I don't know what to do for next encoding... the bigger encoded would need a 80 kbps audio... too bad. I'll try something around CQ=62,5 and see.

As far as I remember CQMatic and Trim are very bad friends.

Welcome to TMPGEnc's CQ roller coaster :!:
You had bad luck, and as I've said before, this CAN happen and I (or anybody else!) can't do a thing about it (for the time being).
The ONLY solution would be to add a final phase of prediction, with a very narrow % of accuracy on wanted size. The problem with this, as you have just experienced, is that with only a CQ difference of 3.57 you have a file size deviation of 78962 KB :!:
And if I implement this in CQMatic to try and zero in closer on the target, which can easily be done, then the time to predict that final CQ will probably be 4 to 5 times the time it normally takes. Probably even longer than a regular 1 pass time of a 2 pass encode.
What really pisses me off, is that I have sent on various ocassions E-Mails to Pegasys, Inc. related to this problem, and they have NEVER answered :(
And I am a registered user of TMPGEnc Plus. So it seems they don't really care about the issue.
I'll just keep trying my best, and I'll try other possible algorithms to see if I can overcome this CQ inconsistency.
I have an idea, but it will be very hard to implement and to maintain, and that is to create a CQ table with 0.1 CQ step increments, and then I will know how much to correct a final CQ value.
The only problem is that if I implement this, every CQMatic version will be tied to a specific TMPGEnc Plus version,
So every time Pegasys, Inc. releases a new version, I would have to rebuild the table with their new encoder, and then release a new version of CQMatic for that particular version.
And it seems that this will be the only way to combat their behaviour :twisted:

Edit:
1) I'll probably start on this right now ;)
2) Instead of a specific version of CQMatic for a specific version of TMPEG, I'll probably release a "footprint" configuration file for each version of TMPGEnc :idea: :idea:
This way, I'll write a small "Generator" program that will encode a specified material in steps of 0.1 CQ values, and then I will have a footprint of how the particular version of TMPEG behaves at different CQ values.

Time to crank up the development system again :!:

-kwag

Karl,

I have an other small problem : on win2000 the tmpgenc window isn't iconified by CQMatic and stay in the front screen :-(

8O 8O 8O 8O 8O
Win2k again :x
I'll take a look.
This just never ends, right? :mrgreen:
But I shouldn't feel that bad, after I see these kind of things (again!) :rotf:
http://p2pnet.net/story/3473

-kwag

This is the second time it happens to Bill while a (quite) important presentation. This can be wished...

(how many media will speak about this and would have never written the word M$ if this "accident" didn't occur ?)

Pain in the A**
Here's what the new CQ curve looks like on TMPGEnc version 2.524.63.181 (Latest)

http://www.digitalfaq.com/archives/i.../2005/01/2.jpg

I didn't put any labels. Left shows file size, bototm shows CQ 40 to 92.
The graph shows a 5 second individual encodes, from CQ=40 to CQ=92.
This is worse than previous versions of TMPGEnc!, as I can see an actual decrease of file size at some increasing CQ value points 8O

-kwag

:drunkard: :dark: :drink: :grenade:

This was the case with some older versions, don't remember which. Needless to say, I ran into it a couple of times :x

:banghead: :banghead: :banghead: :banghead: :banghead:

Kwag, due to that bullshit my little remark:
Theres a executable binary on doom9 of that requantizer, the core also used by Rejig. So at least on DVD-R mpeg2 Targets you can offer an option to slightly increase the float of the CQ value where a requant process afterwards could be 100% fixing processor. The procedure we used in case of overheaded mpeg2 encodings.
For mpeg1, there is one option:
We know that there do exist DVD Folder generating commandline apps, like DVDauthor, so the mpeg1 and sound can be processed for outputting a Video_TS architecture which will be shrinked afterwards (does Rejig accept mpeg1 via authored Image inputs like ShrinkDVD does? If yes than this could be an option. Finally the requantized vob will be demuxed to mpeg1 and mp2 again.

The downside: More time will be needed for that DVDauthoring/filesize/requantize postprocessing and maybe the fine requantizing does destroy the gain of the CQ based encoding.
So thats why the lines above are just an already existing idea from this forum which came into my mind.

Hi guys :),
Let us all flood Pegasys, Inc. email box with this issue.
Like a petition until they, at least, send us an email with an explanation of what we can expect from them in future releases of the encoder.
Who cares to join me?
Cheers

AFAIK Karl already tried to point Pegasys on this non-linear CQ issue in the past. :(

But that was only Karl, that is, a single person.
I mean massive email flooding ;-)
I guess they can't turn their back on us this way.
And if they fix it they'll sell a whole bunch more than they do now.

Good idea Rui :)
Please go ahead, and anyone else who feels can help.
Just imagine if Pegasys would fix the CQ issue and make it linear, CQMatic would predict in 2 or 3 runs :D

-kwag