Support forum for DG Tools

admin wrote: ↑

Mon Jun 25, 2018 8:34 am

DGIndexNV can already demux audio from M2TS. It can also demux subtitles if you open the M2TS stream(s) via the playlist MPLS.

Last time I used DG Tools I only get .dgi + couple audio tracks (.thd .ac3 etc). I will try the latest version of DGIndexNV tonight.

You can subscribe to the Binaries Notification thread to receive notification of new features and bug fixes for all my tools.

I've confirmed that it can demux subtitles. Million thanks.

You're welcome.

Hi.

Found a small issue today.

Seems like the number of subtitles written in the log file is wrong by a factor of 2.

00801 PID 1200 eng.sup [total 4134, forced 0] (the actual number of subs are 2067)
00801 PID 1208 eng.sup [total 2, forced 0] (the actual number of subs are 1)

Otherwise it seems to be working as expected

This is not related to feature requests, but I have been wondering about it for a while, and not been able to find the answer in the manual.

When demuxing AC3 tracks is the Dialog Normalization removed like it is in eac3to by default, or is it something that must somehow be done after the demuxing?

renols

Investigating the subs number issue...

Dialog norm is not removed. I'll look into doing that optionally. Right now, I don't even know what it is.

admin wrote: ↑

Wed Aug 01, 2018 10:14 am

Investigating the subs number issue...

Dialog norm is not removed. I'll look into doing that optionally. Right now, I don't even know what it is.

Hehe.

I have no clue either. Just notice when using eac3to that it removes it per default, and it says that it is not recommended not to remove it.

-keepDialnorm disables dialog normalization removal (not recommended)

Maybe someone else can shed some light on the subject

Thanks for looking into the subs counting issue.

renols

OK, for subs counting I was not allowing for subs that require more than one Object Definition Segment (because they are too large to fit in one). I now read the flag that identifies the first one and increment only when I see that. Will be in the next slipstream.

Looking into dialog norm now...

So, in view of the following link, and the fact that in the entire history of DGIndex and DGIndexNV nobody has ever complained about the demuxed audio not removing dialnorm, I don't plan to do anything about it unless someone makes a very convincing case for it.

https://hometheaterhifi.com/volume_7_2/ ... -2000.html

renols wrote: ↑

Wed Aug 01, 2018 11:05 am

admin wrote: ↑

Wed Aug 01, 2018 10:14 am

Investigating the subs number issue...

Dialog norm is not removed. I'll look into doing that optionally. Right now, I don't even know what it is.

Hehe.

I have no clue either. Just notice when using eac3to that it removes it per default, and it says that it is not recommended not to remove it.

-keepDialnorm disables dialog normalization removal (not recommended)

Maybe someone else can shed some light on the subject

Thanks for looking into the subs counting issue.

renols

eac3to doesn't remove DN on DTS-HD streams (since it never worked anyway).
Before update v3.29, it was only a cosmetic error that says it was removed (when it never really was).
There's lots of posts about it on doom9 forum if you search.

Removign DN is recommended if you want to transcode to a different format.
It's only metadata, no real conversion.

DN is not the same as Dynamic Range Compression, which requires re-encoding the whole stream.

There's a lot of info on doom9 forums:
https://forum.doom9.org/showthread.php?t=158044

Thanks for the info, sparktank!

I've been so used to dealing with just AVC progressive streams, that going back to SD content on DVD (MPEG), I find myself brushing up on things I haven't needed to look up for some time.

Would it, by chance, be too much to ask for a cheatsheet for the info in the *.dgi Files?
The info the DGI files is more relevant than screenshotting the live index with DGdecNV.

Just minor things, like what the colormetry of 2 2 2 means in the file.
Probably just the common and expected (legal) formats allowed.

I keep text files of these, but mainly just for AVC as I tend to neglect anything that doesn't use AVC.

And when I upgrade my card to index HEVC, there'll be more cheatsheets for that as well.

I really can't remember where I keep the free documents on the format specifications.
I should be keeping shortcuts on the desktop in a folder, but I like my desktop super clean.

DGI file formats and semantics are described in the DGIndexNV user manual. Is there something missing?

I'd like a faster way to use video crop, such as it was before the last slipstream.

Could you please make DGIndexNV cropping to interact with template.avs and output the wanted values in DGSource()?

Please

Seems to me you should have brought this up while we were deciding what to do. You're basically asking me to just revert the changes we made.

admin wrote: ↑

Fri Dec 14, 2018 8:35 am

Seems to me you should have brought this up while we were deciding what to do. You're basically asking me to just revert the changes we made.

Sorry, I miss the board for a while and noticed the change when done.

I am not asking to change DGI again with CLIP line.

I am just asking to permit template.avs to receive parameters for ct, cb, cl, cr from DGIndexNV.

Thus doing, nothing would change if nothing is added in template.avs.

It's just a fast and easy way to have a ready AVS script to feed a x264 encoding.

OK, that seems reasonable. I'll see what I can do. We'll need to have __ct__ and similar variables in the template, etc. We can debate whether it should be available via CLI.

admin wrote: ↑

Fri Dec 14, 2018 11:01 am

OK, that seems reasonable. I'll see what I can do. We'll need to have __ct__ and similar variables in the template, etc.

Thanks. That would make life easier when not using a encoding GUI.

admin wrote: ↑

Fri Dec 14, 2018 11:01 am

We can debate whether it should be available via CLI.

IMHO it's a bit hard to clip a video without a GUI, unless you decide to sample some random frames and crop the best case of each of the four sides. Let's think about some IMAX BD, with 2.35 AR on some parts of the movie and then a 1.9 one in others.

Well, now that I am thinking, it could be nice to have an automatic sampling in the GUI too.

Don't push your luck.

Well, now that I am thinking, it could be nice to have an automatic sampling in the GUI too.

I just select three or four spots and compare the crop values

Hi Donald
.mp4 files may include the parameter "Rotation" (in degrees). After demuxing with DGdecNV this parameter gets lost, i.e. it is neither kept in the .dgi nor in the elementary video stream.
Would it be possible to include it at the end of the .dgi (similar to the resolution) ?
Mobile phone video clips can be taken in portrait or landscape (at 0, 90, 180, 270 degrees). Preserving the correct orientation is essential for re-encoding to avoid turned and flipped pictures (I think).

admin wrote: ↑

Fri Dec 14, 2018 2:24 pm

Don't push your luck.

gonca wrote: ↑

Fri Dec 14, 2018 3:29 pm

I just select three or four spots and compare the crop values

Me too. On really old restored movies, such as ones from Criterion, AR varies according to the found positives. It's really hard and time consuming but, hey, we are talking about masterpieces.

'Export to script' checkbox added to Cropping Tool in slipstream 164. Refer to the user manual for proper operation.

Sharc wrote: ↑

Sat Dec 15, 2018 4:47 am

Hi Donald
.mp4 files may include the parameter "Rotation" (in degrees). After demuxing with DGdecNV this parameter gets lost, i.e. it is neither kept in the .dgi nor in the elementary video stream.
Would it be possible to include it at the end of the .dgi (similar to the resolution) ?
Mobile phone video clips can be taken in portrait or landscape (at 0, 90, 180, 270 degrees). Preserving the correct orientation is essential for re-encoding to avoid turned and flipped pictures (I think).

You can't tell what the required rotation is just by looking at the video? I'm reluctant to add container specific data to the DGI file.