06-24-2005, 05:13 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
@Inc: That 2 pass aproach doesn't worth as cq given in HC Encoder log file is not the correct when used in cqmaxbitrate mode as in this mode the encoder do "cut" bits that doesn't brings back to the stream.
If you use cq mode, you have a high probability that your streams can't be load in any dvd author program, neither play in any SAP.
|
Someday, 12:01 PM
|
|
Site Staff / Ad Manager
|
|
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
06-24-2005, 05:45 PM
|
Free Member
|
|
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Yep thats what I called "the issue Ive heard/read of".
So maybe that will be fixed sometime in the near future as its possible to do mpegencoding by keeping the compilancy in CQmode without "cutting" peaks afterwards .... but I do keep my head low as I dont have any clue about that complex programming of an mpegencoding engine from almost scratch.
The used avg Quant CAN be parsed afterwards by HC encoder and putted/changed in the log. Thats stored in the flow of the mpegstream somewhere I dont know exatly ... as Bitrateviewer is also able to parse the FINAL existing Q values out of a ready encoded mpeg stream. So a final last step mpeg parsing could switch that value in the log text.
|
07-03-2005, 09:40 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
|
07-05-2005, 06:20 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
I don't understand why all about calcumatic/cqmatic is here in this thread. It seems that we don't open more threads in this subforum and I don't know why.
But anyway:
@Kwag: Could you explain me this:
You can see that calculated avg bitrate = 5511.9 kbps
103' 49'' = 103,8206667 min
103,8206667 * 60 * 5511.9 / 8 = 4291868 KB
And calcumatic shows 4191088.
Similar about audio:
103,8206667 * 60 * 384 / 8 = 299003 KB
Why calcumatic does it in this way?
|
07-05-2005, 06:37 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Prodater64
You can see that calculated avg bitrate = 5511.9 kbps
103' 49'' = 103,8206667 min
103,8206667 * 60 * 5511.9 / 8 = 4291868 KB
And calcumatic shows 4191088.
Similar about audio:
103,8206667 * 60 * 384 / 8 = 299003 KB
Why calcumatic does it in this way?
|
Because you're missing a small detail
( 103,820.6667 * 60 * 5511.9 / 8 ) / 1.024 = 4191277 KB
And ( 103,8206667 * 60 * 384 / 8 ) / 1.024 = 291995 KB
(Results are rounded)
That's why CalcuMatic will give you EXACT results, and you can confirm that if you do an average bitrate encode (2-pass), and then compare the file size on disk (with Windows file manager) against the size CalcuMatic gave you. The result will be almost identical
-kwag
|
07-05-2005, 06:39 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Also I misstyped , (commas) by . (point) as in north american way.
|
07-05-2005, 06:44 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Prodater64
Also I misstyped , (commas) by . (point) as in north american way.
|
I know 
Took me a second to figure it out
-kwag
|
07-05-2005, 07:28 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Then if:
(103.8206667 * 60 * 5511.9 / 8 ) / 1.024 = 4191277 KB results are KB
what units are
(103.8206667 * 60 * 5511.9 / 8 ) = 4291868
|
07-05-2005, 07:43 PM
|
Free Member
|
|
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Prodater64
Then if:
(103.8206667 * 60 * 5511.9 / 8 ) / 1.024 = 4191277 KB results are KB
what units are
(103.8206667 * 60 * 5511.9 / 8 ) = 4291868

|
Kilobytes. Based on 1000 bytes, instead of 1024 bytes.
-kwag
|
07-07-2005, 05:11 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Hmm...
Since you're dividing by 1024 to get to Kilobytes, it means the previous figure should be bytes based in 1000.
Am I right?
__________________
Rui
|
07-07-2005, 05:28 AM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
Hmm...
Since you're dividing by 1024 to get to Kilobytes, it means the previous figure should be bytes based in 1000.
Am I right?
|
Not.
He is dividing by 1.024 (decimal number).
|
07-07-2005, 08:04 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
No he is not.
He's grouping digits  .
1 Kilobyte is not == 1,024 bytes.
1 kilobyte is == 1024 bytes.
That's what Karl is doing.
He is dividing by 1024 to reach Kilobytes.
Cheers
__________________
Rui
|
07-07-2005, 08:34 AM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
No he is not.
|
Yes he is
Quote:
He's grouping digits .
1 Kilobyte is not == 1,024 bytes.
1 kilobyte is == 1024 bytes.
That's what Karl is doing.
He is dividing by 1024 to reach Kilobytes.
Cheers
|
Karl is is dividing by 1 dot024. Not 1024 (that is 1 comma024).
And he does so because "5511.9" is already in 'kilo' (kbps = kilo bit per second)
The problem is : is 5511.9 in base 1000 or 1024 ? That is perhaps the question you asked Rui.
|
07-07-2005, 01:25 PM
|
Free Member
|
|
Join Date: May 2002
Posts: 438
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Phil,
let me answer for Rui:
in portuguese, the decimal separator is "," (comma) while the thousands separator is "." (dot) - that's why the confusion.
so one and twenty four thousenths is 1,024 ("in portuguese") and 1.024 ("in english") ;
One thousand and twenty four is 1.024 ("in portuguese") and 1,024 ("in english").
|
07-07-2005, 02:37 PM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by GFR
in portuguese, the decimal separator is "," (comma) while the thousands separator is "." (dot) - that's why the confusion.
|
I know. That's the same in all Europe.
|
07-09-2005, 08:56 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Ok.
I got it all wrong 
Karl was really talking about 1 dot 024.
I did get confused because usually in my calcs I use bytes and not kilobytes where I divide by 1024 to reach kilobytes in the end.
Sorry guys.
BTW I don't see why doing the calcs using movie time in minutes and seconds while we can do it in frames which is a much more accurate measure.
Cheers
__________________
Rui
|
07-09-2005, 10:07 AM
|
Free Member
|
|
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
BTW I don't see why doing the calcs using movie time in minutes and seconds while we can do it in frames which is a much more accurate measure.Cheers
|
To avoid confusion between 23.976 and 23,976
|
07-09-2005, 10:24 AM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
Ok.
... BTW I don't see why doing the calcs using movie time in minutes and seconds while we can do it in frames which is a much more accurate measure.
Cheers
|
BTW Did you test and compare ProCalc, based on Boulder spreadsheet?
|
07-09-2005, 11:00 AM
|
Free Member
|
|
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Dialhot
To avoid confusion between 23.976 and 23,976 
|
You joker
Quote:
Originally Posted by Prodater64
BTW Did you test and compare ProCalc, based on Boulder spreadsheet?
|
Not yet.
My PC won't let me.
I mean I have downloaded ProCalc and all but it won't start even with the VB6 runtimes...
Too many DLL's all screwed up or something.
It's a miracle that I can still browse the web on FireFox.
It's slow as hell and I was blaming my ISP  .
All started happening from the moment I installed avast for testing and they uninstalled it to go back to avg free  .
avast uninstaller presented me with tons of errors and froze my pc.
I had to hard reset it and then I got presented with a lot of errors on boot.
I shall reinstall XP and I'll let you know then.
When will I learn that I must do some XP images for times like this when things get difficult 
Cheers
__________________
Rui
|
07-09-2005, 06:39 PM
|
Free Member
|
|
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by rds_correia
BTW I don't see why doing the calcs using movie time in minutes and seconds while we can do it in frames which is a much more accurate measure.
Cheers
|
ProCalc info minutes and seconds so in that way ASPA (Available Space Proportional Allocation) is compatible in a straight way with CQmatic, as it require min and sec as input plus avg btr and TMPGEnc project. But, "in fact" ProCalc do all calculations based on frames and fps.
You know, same than Boulder spreadsheet.
|
All times are GMT -5. The time now is 01:14 AM — vBulletin © Jelsoft Enterprises Ltd
|