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. |
10th September 2007, 10:30 | #22 | Link |
Junglist
Join Date: May 2003
Location: Belarus, Minsk
Posts: 298
|
But, maybe, such an option will be more convinient and more universal(can i use this word in this context?)
__________________
Rule Number 6: Concentrate!!! (c)Hercules, Disney "I like to build planes.... in the air" (c) some ADV. tutorials How to Setup agent-based encoding with x264farm (the easy way) |
12th September 2007, 01:24 | #23 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
DGMPGDec 1.5.0 beta 2
* The file type .m2t was added to the open dialog.
* Some array sizes were increased to prevent crashes in the debugger. * The next_start_code() function was enhanced to add error resiliency for abnormal slice terminations. * Because the code never writes to the DirectDraw surface anymore (removed long ago!), the DirectDraw Overlay option was removed. DGIndex now never seizes the overlay. http://neuron2.net/dgmpgdec/dgmpgdec150b2.zip |
13th September 2007, 09:23 | #24 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Are you interested in taking a look at a sample in which the delay is way off target?
The reason why I ask you first is that the bad VOB is the result of RipIt4Me+FixVTS, a good delay value is found when the disc is decrypted using DVDFab HD Decrypter. PGCDemux does show the correct value from the bad VOB so it is there somewhere The disc is ARccOS protected (a Sony release) if I'm not mistaken. Since many people still use RipIt4Me, it might be interesting to know whether this odd behaviour could be avoided in DGIndex (which is used by many applications).
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
13th September 2007, 16:11 | #26 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Here it is : http://www.savefile.com/files/1052641
DGIndex 1.5.0 beta 2 reports delay 81112ms, the correct is apparently -128ms which PGCDemux reports, it is also the same value that DGIndex reports when processing the DVDFab HD Decrypter-ripped VOB.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
13th September 2007, 19:14 | #27 | Link |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,227
|
I've just run your .VOB sample thru' EVOdemux and it reports the same delay time as DGIndex.... Strange eh!
Cheers
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
|
13th September 2007, 19:18 | #28 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Funny thing is that PGCDemux doesn't find any audio tracks when opening the corresponding .ifo file and using "by PGC" mode. The whole audio track can only be found if I use "by VOBId" and choose the correct VOBId. (choosing "by cell" works as well but it shows the delay only for the cell in question)
Maybe this is the reason for the weird delay?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
13th September 2007, 20:30 | #30 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Actually no, this is the first time I've run into this problem. If it solves the issue, what about those applications that use DGIndex, such as DVD-RB? That trick cannot be used with them.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
13th September 2007, 21:11 | #31 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Yep, jumping a few GOPs seems to work. I wonder how DVD-RB or MeGUI would behave..I think I'll need to run a test project and see what comes out.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
16th September 2007, 16:13 | #33 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
1. When you say 'relative', do you mean relative to the path location of the D2V file? That path is to be the base location for everything else, yes? 2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example: ..\d:\path\file.vob So how do you intend to use this relative path capability in this scenario? Last edited by Guest; 16th September 2007 at 16:18. |
|
16th September 2007, 17:23 | #35 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
That's a good idea - especially because it has been quite rare but apparently has become more common due to the structure crippling protections.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
16th September 2007, 18:20 | #36 | Link |
Registered User
Join Date: Aug 2002
Posts: 87
|
Just force the storage of absolute paths. Though it doesn't seem that he'd like to use the relativeness feature this way, but simply being able to move the directory structure including the project file from a local hard drive to a network store, without editing d2v internals manually.
Last edited by Rainy; 16th September 2007 at 20:51. |
17th September 2007, 08:52 | #37 | Link | |||
Junglist
Join Date: May 2003
Location: Belarus, Minsk
Posts: 298
|
Quote:
Quote:
Quote:
just store "d:\path\file.vob" it is, like, for moving files from one drive to another without loosing playability and encodeability.. without editing .d2v's or making another Indexing..
__________________
Rule Number 6: Concentrate!!! (c)Hercules, Disney "I like to build planes.... in the air" (c) some ADV. tutorials How to Setup agent-based encoding with x264farm (the easy way) |
|||
17th September 2007, 13:58 | #38 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
You're not answering my question. What is the point of me adding relative path handling for this networking scenario, which you cited as a reason for adding it? We can already store full paths. If you don't make things clear I'm going to move on.
Quote:
I'm just not seeing the point of all this. Last edited by Guest; 17th September 2007 at 14:01. |
|
17th September 2007, 14:29 | #39 | Link |
Registered User
Join Date: Aug 2002
Posts: 87
|
You're mixing things up: Absolute paths have to be stored whenever the project and video files don't share a common prefix, i.e. are located on different drives, *even* if the user chooses paths to be stored relatively. This is a special handling for the scenario you've mentioned before, since there's no such a thing as relativity between different drives In any other case you simply store relative paths, which makes it possible to move files around and never have to edit the project file.
|
17th September 2007, 14:37 | #40 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Ha ha, I'm not an idiot. I'm asking for justification for the feature. If the only thing he wants is to store his source files away from his D2V, then it's too minor to jump ahead of other stuff on my to-do list. If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.
Last edited by Guest; 17th September 2007 at 14:50. |
Thread Tools | Search this Thread |
Display Modes | |
|
|