Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
29th November 2011, 10:05 | #201 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
@Selur : What the status of information/formulas of DTS-HD MA 2.0 ? If i remember properly, you had several sources and "lot" of information with DTS-HD MA 5.1, but few of 2.0. You made a google excel somewhere, no ?
|
30th November 2011, 02:54 | #202 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
Status hasn't changed since I gave up on it. I really don't have much samples or data to start with,..
https://docs.google.com/spreadsheet/...hl=en_US#gid=0 and https://docs.google.com/spreadsheet/...hl=en_US#gid=0 were this I did 1/2 a year ago, but the formulas there are far from being usable,... Cu Selur |
30th November 2011, 09:51 | #203 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
If i remember correctly, you have relatively good working formula for DTS-HD MA 5.1 (because you have a lot of datas), but unfortunately, only one data of 2.0, and formula is not as good with it, but with only one data, it's normal. I can provide you at least another data of 2.0 stream, of about 1h30, wich will provide you 2 packs of data with different duration. So :
1 : Do you think this can help you to improve/tune formulas for DTS-HD MA 2.0 ? 2 : Are you still interested in trying to improve it ? Your formula in post 141 gives good result with 5.1 and 7.1 according the Excel sheet, at this point, without the specific blu-ray spec, i don't think improvement can be made. But, maybe with a little more datas, improvement can be made on 2.0. Last edited by jpsdr; 30th November 2011 at 10:01. |
16th January 2014, 01:15 | #204 | Link |
QB the Slayer
Join Date: Feb 2011
Location: Toronto
Posts: 697
|
Sorry for bringing up an old topic, but it's long over due for MeGUI's bitrate calculator to be fixed. I just recently did an encode after a very long time and decided to try the BC in MeGUI one more time since it's been many updates since the last time I used it... After muxing to Blu-Ray structure (ie. m2ts) it came up 102% in Imgburn... argh! Still not fixed... so I pulled up my calculations (I used to do BD5's and BD9's) and attempted it for my first BD25 encode. Result was 99.25%. So I searched for this topic and thought I would share my results in the hopes this can be fixed.
I break things down into 3 overheads (o/h) in kbps: Video, Audio and Blu-Ray structure. I didn't take the approach of an o/h as a size, but instead looked at it as a rate. We know what the capacity of a disc is, and as such the maximum bitrate it can hold for a given movie; and we know the bitrate of the audio... calculating the video bitrate should follow pretty easily. Since we are trying to calculate a bitrate to encode at, it made sense to do it this way. First step is easy.... Blu-Ray folders always have the same size when using tsMuxer: 655,360 B so that o/h is simple. To find the Video o/h, I would just mux the encoded video in an m2ts from RAW and compare the RAW vs m2ts file size and when plotted as bitrates this is what we get: As you can see, Video o/h is a perfect line. Next up is Audio o/h... I would go back to tsMuxer add the Audio and then mux again. By taking the resulting m2ts and subtracting the audio, video and video o/h, we get the audio o/h. Again, I looked at this as a bitrate and a few things became very clear. DTS is easy: That's an average value of 220.58 kbps... a fixed o/h for a fixed bitrate. For DTS-HDMA it's a little different since the bitrate of the audio file is not fixed like DTS and as such the o/h is not fixed either. And here are those results: Again we see a very clear equation emerge. Armed with these 3 equations for o/h (Video, DTS and DTS-HDMA) it is not very difficult to come up with a calculated video bitrate. After I started this posted I realized a few things. One, I was using the "Size on Disk" values for most (if not all) of the size (B) values... and that is not correct. Secondly, I have a large collection of video files I can pull apart and remux to get an even better set of data points for all kinds of differing audio formats and configurations. I had just been collecting data as I encoded things, but I may do a few daily and re-do my spread sheet with more data and proper sizes recorded. And finally, I realized that subs too must have an o/h, and even though they take up a small % of the file size, it may be a good idea to investigate this further too. I hope this helps to get the MeGUI bitrate calculator fixed QB
__________________
|
16th January 2014, 03:08 | #205 | Link | ||
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,546
|
Before tsMuxeR 2.0.8b rhythm of insertion of PAT/PMT packs was as follows: (PAT/PMT/SIT: every 285ms).
From tsMuxeR 2.0.8b on the rhythm of insertion of PAT/PMT packs happened more often (PAT/PMT/SIT: every 94ms) Quote:
From tsMuxeR 2.1.6b on mux overhead has been reduced again. Quote:
So overhead results will differ with muxer versions.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..." Last edited by Emulgator; 16th January 2014 at 03:14. |
||
16th January 2014, 04:18 | #206 | Link |
QB the Slayer
Join Date: Feb 2011
Location: Toronto
Posts: 697
|
Indeed... but MeGUI still uses 1.10.6 and as such it's the calculator that is broken and should be fixed and I thought this was the thread that was going to be used to help fix it... if I am wrong I apologize.
QB
__________________
|
16th January 2014, 05:57 | #207 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
MeGUI is using tsmuxer version 2.6.11 here. I've no idea how that version effects the accuracy of the bitrate calculator (I never use it myself) but maybe try switching to the development update server and updating whatever needs it. I've been running the latest MeGUI version (2460) since it hit the development update server without any problems.
Then again, the bitrate calculator wiki page has this to say: http://mewiki.project357.com/wiki/Me...ate_Calculator Note: The M2TS calculation is a WIP. Also, the quality estimate may require further refinement. |
16th January 2014, 06:02 | #208 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
Since the current m2ts calculation code is based on the code I came up with for Hybrid back when this thread was active before, I could share my current m2ts methods (which I use in Hybrid nowadys) with the MeGui devs if they are interested.
I adjusted my old code after the new tsMuxeR version appeared. Difference between this code and the old code isn't really much, so adjusting the m2ts size calculation in MeGui shouldn't be hard. Problems of my code: a. 2.0 DTS-MA overhead estimation could be better (didn't have much data to adjust it) b. true-hd overhead calculation is a WILD GUESS and as much off as before c. formulas are mainly data driven and their main goal is to make sure the calculated overhead is always larger than the actual occurring one so that the resulting file size will not exceed the target size -> they don't try be too accurate since accurate calculations would require to know the actual frame sized of the audio&video frames d. subtitle and structure sizes are simply used as fixed sizes since I never did any testing in how much overhead they really create e. no clue if the video overhead is still correct for 3D content, since I don't have any data about 3d content f. formula is ment for 2pass encoding (since only then does file size estimation make any sense; at least for me) g. code isn't really documented, but since I use decent variable names the code should be easy to read an follow and quite similar to MeGuis current code Cu Selur |
16th January 2014, 13:22 | #209 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
Quote:
For .pes file in Scenarist my results show around 15%. Last edited by jpsdr; 16th January 2014 at 13:24. |
|
16th January 2014, 13:29 | #210 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
@jpsdr: that was due to a problem with the board where I didn't get any email notifications (also I would need the data of multiple sources)
Quote:
|
|
16th January 2014, 13:53 | #211 | Link |
Registered User
Join Date: May 2006
Posts: 3,997
|
Has anyone tried / compared with this calculator?
It claims to be fairly accurate. Not sure if it's still maintained for new tsMuxeR.... |
|
|