Issue with path
Issue with path
Go for it, Sherm! You know you're my hero.
Issue with path
We all need this right about now. Crank the volume.
Kisses, Brit
Kisses, Brit
Issue with path
That's me in the red dress, in case you didn't know.
Issue with path
Can link original Jimi Hendrix Pali Gap, no covers. Try find that online. Lawyers on you so fast need butthurt cream. Send PM. Gold coin included. No regrets.
Issue with path
Do it!
Issue with path
The first minute will destroy everything you thought you knew. Life will never be the same for you. Is that what you really want?
Issue with path
Do it!!!
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Issue with path
Doing a Pali Gap cover is like saying look how bad I suck.
Issue with path
I wish he would love me.
Issue with path
I have setup DGIndexNV in StaxRip according to JKyle guide from forbidden forum
I have crashed against the accented vowels problem that arose some time ago. I "fixed" it, manually avoiding to use any in the path of dgi, dgi name, etc but having to batch demux and encode thru staxrip something like 80 files, manually renaming path and names and then recover them to the original format is a no go.
If I recall well, everything started with the Unicode version of DGTools.
Would you please try to help me to fix it or release a non unicode version of it?
Thanks.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
I have crashed against the accented vowels problem that arose some time ago. I "fixed" it, manually avoiding to use any in the path of dgi, dgi name, etc but having to batch demux and encode thru staxrip something like 80 files, manually renaming path and names and then recover them to the original format is a no go.
If I recall well, everything started with the Unicode version of DGTools.
Would you please try to help me to fix it or release a non unicode version of it?
Thanks.
Issue with path
Doom9 has not been forbidden for years.
Please post a link to a file with a name that causes such problems. Alternatively give just the filename here.
There is no unicode version. You simply enable or not the included manifest, as described in the included UTF-8 document.
Please post a link to a file with a name that causes such problems. Alternatively give just the filename here.
There is no unicode version. You simply enable or not the included manifest, as described in the included UTF-8 document.
Issue with path
Rename whatever mkv file to a name such as àncora.mkv.
Index it to àncora.dgi and feed to some GUI encoder such as StaxRIP, without enabling beta unicode support in Windows.
Tell me about results.
I have tried the Staxrip FFVideoSource indexer and got no errors.
Issue with path
When I use MeGUI to open the DGI everything is fine. And VirtualDub2 can open the avs script. But staxrip passes this as "dgi" to DGSource:
à ncora.dgi
I don't know why staxrip is doing that.
à ncora.dgi
I don't know why staxrip is doing that.
Issue with path
Staxrip is a UTF-8 application. To make it work you have to remove the ~ from the DGIndexNV manifest file before launching DGIndexNV and doing save project, in order to create a UTF-8 DGI file. Then the DGI file will be opened by staxrip and you can encode etc. The UTF-8 DGI file will be unusable in apps that don't support UTF-8, such as VirtualDub2.
"The question is why does it work with "internal" indexers such as FF and Lsmash."
They are being told to write their index files as UTF-8.
"The question is why does it work with "internal" indexers such as FF and Lsmash."
They are being told to write their index files as UTF-8.
Issue with path
That's exactly what I tried too and I get:
![Image](https://i1.lensdump.com/i/ghecmc.png)
Content of avs:
SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\àncora.dgi")
First lines of DGI:
DGAVCIndexFileNV23 DGIndexNV 238.0.0.0 X64
D:\Eseguibili\Media\DGDecNV\
G:\Raw\àncora.mkv 1377383877
Has it something to do with the fact that I am using the italian version of Windows?
EDIT: On the second time I have launched DGIndexNV, it created UTF-8 AVS and DGI, while the first time it created them in ANSI format. Now it seems to work. I will send you some more feedback later if I will find something strange.
EDIT 2: FFMS2 creates a UTF-8 file but it is perfectly readable both in StaxRip (obviously) and VirtualDub too. Opening the two AVS files, I can find some discrepancies in codetables, as reflected from the following images from Notepad3
àncora_FFMS.avs
![Image](https://i3.lensdump.com/i/ghewAZ.png)
àncora_DGNV.avs
![Image](https://i.lensdump.com/i/ghexQP.png)
EDIT 3: I opened both files in a hex editor and you can see the differences:
àncora_FFMS_hex
![Image](https://i2.lensdump.com/i/ghe55i.png)
àncora_DGNV_hex
![Image](https://i3.lensdump.com/i/gheaTo.png)
- Attachments
-
- àncora_DGNV.avs
- (141 Bytes) Downloaded 632 times
-
- àncora_FFMS.avs
- (362 Bytes) Downloaded 605 times
Issue with path
The FFMS file is not UTF-8. It is extended ASCII (codepage 1252). I do not have any plans to generate extended ASCII files in DGDecNV. You have UTF-8 if you ask for it with the manifest, or you have whatever is defined in your system locale.
Issue with path
A doubt arose in my brain: why, if DGIndexNV avs and dgi are UTF-8, the "à" vowel is not displayed correctly in all the text editors I have tried, when choosing UTF-8 as text encoding?
Notepad3, Windows Notepad and UltraEdit recognize them as ANSI Latin I or Western Europe (Windows or ISO).
VSCode open them correctly with Windows 1252 encoding only.
Can you please check it? I think that something is wrong.
Issue with path
Look here at entry 224:
https://www.charset.org/utf-8
The hex value for the accented a is C3 A0. If you look at the hex dumps for the DGNV-generated files you will see the C3 A0 values, so that is how you know it is encoded in UTF-8 (see PS below). There is no UTF-8 BOM; perhaps that explains why some apps do not recognize them as UTF-8. I don't know.
PS: Looking again at your dumps... Your hex dump labels are reversed and the DGNV one (after correcting the labels) appears to have been generated without the manifest enabled and so is 1252 (extended ASCII). Re-generate the DGNV files with the manifest enabled and you will see the C3 A0 values. The FFMS dump has the C3 A0 values and so is UTF-8 (contrary to what I said earlier based on your reversed labels).
https://www.charset.org/utf-8
The hex value for the accented a is C3 A0. If you look at the hex dumps for the DGNV-generated files you will see the C3 A0 values, so that is how you know it is encoded in UTF-8 (see PS below). There is no UTF-8 BOM; perhaps that explains why some apps do not recognize them as UTF-8. I don't know.
PS: Looking again at your dumps... Your hex dump labels are reversed and the DGNV one (after correcting the labels) appears to have been generated without the manifest enabled and so is 1252 (extended ASCII). Re-generate the DGNV files with the manifest enabled and you will see the C3 A0 values. The FFMS dump has the C3 A0 values and so is UTF-8 (contrary to what I said earlier based on your reversed labels).
Issue with path
Content of my DGIndexNV directory:
Code: Select all
13/08/2021 02:12 12.288 chapters2qp.exe
27/11/2021 12:44 211 demux2732.txt
08/12/2021 22:42 3.764.224 DGDecodeNV.dll
05/11/2020 18:28 28.632 DGDecodeNVManual.html
27/11/2021 14:15 236.032 DGDemux.exe
17/12/2021 17:00 1.352.704 DGIndexNV.exe
22/12/2021 17:42 950 DGIndexNV.exe.manifest
22/12/2021 17:43 1.137 DGIndexNV.ini
26/04/2021 18:23 120.855 DGIndexNVManual.html
13/09/2010 23:46 167.936 DGSplit.exe
07/08/2021 22:48 2.353 FragmentedMP4.txt
28/03/2019 10:28 43.556 gpus.txt
18/01/2021 13:34 63 license.txt
07/08/2021 21:56 276.992 mp4demuxer.exe
26/04/2021 18:24 7.122 QuickStart.html
28/04/2021 14:26 2.396 Readme.txt
22/12/2021 09:03 1.576 template.avs
25/01/2021 18:21 1.298 UTF-8 Notes.txt
30/03/2018 13:59 972 Vapoursynth Notes.txt
30/10/2021 18:43 <DIR> x86
Code: Select all
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<assemblyIdentity type="win32" name="..." version="6.0.0.0"></assemblyIdentity>
<application>
<windowsSettings>
<activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
</windowsSettings>
</application>
<dependency>
<dependentAssembly>
<assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
EDIT 1: please have a look at http://csi-windows.com/toolkit/manifestutils and at https://answers.microsoft.com/en-us/win ... d16324444c . What version of Windows are you using and what value do you have in that key?
EDIT 2: I have manually inserted that key in the registry and now everything seems working. Perhaps you should add something in the manual. I will attach both keys to enable and disable the external manifest priority.
- Attachments
-
- PreferExternalManifest.zip
- (629 Bytes) Downloaded 565 times
Issue with path
Oh yeah, I forgot about that. I'll update the UTF-8.txt file. Thank you! ![grateful :salute:](./images/smilies/icon_salute.gif)
![grateful :salute:](./images/smilies/icon_salute.gif)
Issue with path
Updated 238: UTF-8.txt and a reg file.
We gotta stomp out everything but UTF-8.
We gotta stomp out everything but UTF-8.
Issue with path
I was able to get the UTF-8 DGNV files to play nice with VirtualDub2. Do this:
1. Add the PreferExternalManifest reg file to your registry.
2. Copy the DGIndexNV manifest file to the directory of VirtualDub2 and rename it to VirtualDub64.exe.manifest.
3. Now VirtualDub2 can open the UTF-8 DGNV files.
Great, that's nice. Seems we can force any application to use UTF-8 this way. Gonna try with MPC-HC now. If that works, I'll probably leave my DGNV manifest enabled all the time.
The DGSource() DLL does not use a manifest. It is governed by the invoking application, VirtualDub, staxrip, MPC-HC, etc.
EDIT: Halleluja. It works with MPC-HC. I can open and play UTF-8 scripts generated by DGIndexNV. Gonna leave my manifest enabled and see how things go. I have DGIndexNV, VirtualDub2, MPC-HC, and MeGUI all working in UTF-8 using manifests. Notepad++ and staxrip already support UTF-8 natively. I'll deal with other applications as and when issues arise. UTF-8 rules!
1. Add the PreferExternalManifest reg file to your registry.
2. Copy the DGIndexNV manifest file to the directory of VirtualDub2 and rename it to VirtualDub64.exe.manifest.
3. Now VirtualDub2 can open the UTF-8 DGNV files.
Great, that's nice. Seems we can force any application to use UTF-8 this way. Gonna try with MPC-HC now. If that works, I'll probably leave my DGNV manifest enabled all the time.
The DGSource() DLL does not use a manifest. It is governed by the invoking application, VirtualDub, staxrip, MPC-HC, etc.
EDIT: Halleluja. It works with MPC-HC. I can open and play UTF-8 scripts generated by DGIndexNV. Gonna leave my manifest enabled and see how things go. I have DGIndexNV, VirtualDub2, MPC-HC, and MeGUI all working in UTF-8 using manifests. Notepad++ and staxrip already support UTF-8 natively. I'll deal with other applications as and when issues arise. UTF-8 rules!