Log in

View Full Version : VobBlanker 2.1.1.0 Released


Pages : [1] 2 3

jsoto
8th January 2006, 23:45
Hi all,

2.1.1.0 release announcement
http://forum.doom9.org/showthread.php?p=828889#post828889

Here is the (previous) 2.1.0.0 version changelog:

Changelog
Added:Title PGCs and Menus(full domain) Tiny Preview in main dialog. Note: Some new settings including one to disable tiny preview have been added.
Added: Ability to fix SRI and SYNCI pointers in Menu domains.
Added: Split-Cell ability in Titles domain. Splits a Cell and can add a new Program and a Chapter. Multiple splits (in different cells) are allowed in the same process session
Added: VID/CID renumbering ability. Selected as default instead of filling the VID/CID sequence with blank cells.
Added: Motion2still accepts external I-Frames, from a VOB or bmp. bmps are converted using MuxMan.
Added: Drag and Drop in preview pane (used in motion2still)
Added: Tools menu to select external tools and Temporal folder
Added: html links in Main Menu to homepage and guides
Added: Registry key with the Version
Added: Detection of ini/end cell pointers out of range.
Added: VOB files FullScan: used to get the right cell ini/end pointers
Added: Detection of cells in PGCs not listed in C_ADT tables
Added: Detection of pointer mismatches between C_ADT and PGC tables.
Added: Detection of possible orphan subs in cell split and title cut.
Added: Check if any offset is out of IFO range (C_ADT, M_C_ADT, C_ADMAP...).If yes, issue a warning and change it to zero.
Added: CLI options to run minimized (-min) and to run a fullscan (-scan). If scan is selected in CLI the related errors loading IFOs are skipped.
Added: Menu option "Save project" added ("Save project as" was already there).
Improvement: Window titles in Menus/Preview and Cell dialogs show the VTS and other useful info.
Improvement: Playing a PGC in the preview automatically changes the Cell at the end of the current one
Improvement: Some improvements opening the preview window to show the previous (if any) selected frame
Improvement:Motion2still: Some improvements, mainly in motion2still w/o audio (I hope I didn't break anything). Now the output is much more similar (probably identical in motion2still w/o audio) to menushrink one.
Improvement: Motion2still: Changed Highlight status to 1 in nav still. The value should be there, but in some rare cases could not be set in the original.
Changed: Registry keys and project keys re-organized in sections in a more clear way. VobBlanker deletes automatically the old keys, but two reg files are attached to manually clear the registry.
Changed: Default values changed to yes in "blank cells w/o buttons" in motion2still and "Clear audio/subs status when blanking" in menus domain.
BugFix: Playback tables cell flags and still times are now modified depending on how the cell has been processed, instead of how the PGC has been processed. This should be the same for non reused cells, but in the case of reused cells the previous method did not work at all.
BugFix:Video Attributes (resolution) were not correctly mapped.
BugFix: Replacing reused cells failed
BugFix: Some minor problems in menu final size estimations
BugFix: Subs SYNCI pointers: In the case of two subs in the VOBU, was pointing to the second one instead to the first one
BugFix: Audio SYNCI pointers: Sometimes VobBlanker was pointing to the audio pack before the right one.
BugFix: Motion2Still: Fixed the case when the subs appear two VOBUs before the buttons (Star Wars I japanese version).
BugFix: Two bugs in Motion2Still in titles domain.
BugFix??: Disappearing buttons issue: Not found the root cause, but coded a walk around (little dirty, BTW).



VobBlanker Navigation links
Versions <= 1.5 discussion thread:
http://forum.doom9.org/showthread.php?s=&threadid=73145
Versions = 1.6 discussion thread:
http://forum.doom9.org/showthread.php?s=&threadid=86437
Versions = 2.0.0 discussion thread:
http://forum.doom9.org/showthread.php?t=92481
Versions = 2.0.1 discussion thread:
http://forum.doom9.org/showthread.php?t=100213

2.1.0.0 release candidate thread
http://forum.doom9.org/showthread.php?t=105194

2.1.1.0 release announcement
http://forum.doom9.org/showthread.php?p=828889#post828889

jsoto

arsmori
9th January 2006, 02:23
w00t! :D Love the Tiny preview so far, save a step or two and makes my index finger happy. I miss the secondary progress bar though, it was useful for pointers fixes that takes a while. Maybe you want to export the *.reg files as version 4 (Win9x/NT4) in case there's still some win9x users out there, just a though.

dirio49
9th January 2006, 02:25
thanks jsoto.:)

blutach
9th January 2006, 03:21
Another wonderful piece of work. Can not say enough thanks.

http://www.digital-digest.com/~cynthia/beta/0038.gif

Regards

jsoto
9th January 2006, 22:40
Many thanks for your enthusiasm. I appreciate it.

jsoto

nemo21
11th January 2006, 18:54
This version of Vobblanker is excellent. The small preview works so much better for me. I can't thank you enough for your work on this program!

The only thing I can think of to improve the program would be to create an expandable/collapsable icon next to multi-cell VOBs so you could blank selected cells in the main window, previewing them in the small preview window.

Oh, actually, there is one other thing. I use the program mostly for episodic DVDs or things like animation collections. For these type of DVDs, I want to blank one half, backup, and then blank the other half. For animation collections like the Disney Treasures collections, the cartoons are often all in one massive VOB, so I blank half of them at a time in the cell window. After I process and get the 1st of 2 dvd file sets that I will use to back up the original, the process window is greyed out. If I change the target folder or the cells that are blanked, it remains greyed out. I have to re-load the .ifo to change which cells are blanked and process the other half of the disc. When I reload the .ifo, though, I lose the information about what cells I blanked for the 1st run. So, I need to write down the cells I blanked on the first run and blank the other cells on the 2nd run. I wish there was a way to allow me to blank different cells and reprocess without re-loading the .ifo so that I didn't have to write down all of the cells I blanked on the first disc. That was a really long-winded explanation and it probably took me longer to write it than it takes to write down the cells I blanked but there it is--that feature would make the program even better for me.

Thanks again for your efforts!

jsoto
11th January 2006, 19:33
After I process and get the 1st of 2 dvd file sets that I will use to back up the original, the process window is greyed out. You're not the first one asking for this... The reason to grey-out the process button is that some internal vars have been modified after the process and I need to reload them.
There is a simple tip.
- Save your project (from main menu). You can do it even if the 1st part has been processed and the process button is greyed.
- Load the project. Process button will be enabled again, and all the settings (cells to be blanked, and, in general, all the things you have selected in 1st run) are recovered from the project file.

jsoto

wmansir
12th January 2006, 00:29
Thanks for the new features jsoto. The tiny preview is great, since I preview just about everything it's really a time saver.

I also wondered about the greyed out process button and have used that tip method on several occations. Thanks for explaining why it works that way.

winny
12th January 2006, 01:46
Just wanted add another sincere note of thanks for a superb program.

Thank you :)

Sir Didymus
23rd January 2006, 14:35
I think there is something wrong in the calculation of the TMAPTI table performed by VobBlanker (apart the log file, with the "TMPATI" glitch)...

Many entries are flagged as "discontinuity entry" where time codes are not actually discontinuous with previous; also - and more important - the actual values in the table are frequently odd (especially the values starting from the second cell of the PGCs)...

I found this issue just incidentally, while replacing some pgc...

The way to reproduce the problem is quite simple:

1. Start from a video asset and a chapter file demuxed from the main pgc of a movie
2. Plain remux the video with the chapters using MuxMan
3. Check the TMAPTI produced by MuxMan (this table, which is correct, should be used as the reference one)
4. Straight process the title with VobBlanker
5. The TMAPTI produced by VobBlanker is different (entries of wrong values, and presence of discontinuity entries where no discontinuity exist)

If useful I can give specific examples of "wrong" entries... but I say again, it is quite immediate to reproduce the issue...

Cheers
SD

jsoto
24th January 2006, 01:49
Well, this is something not totally clear to me, but....
a) discontinuities
I've used IFOEdit as the reference (before MuxMan exists), and IFOEdit marks the last entry of each cell in TMAPTI table as discontinuity. I never understood this completely, but all the originals I looked into, they also do it. So, in this particular case, I think Muxman is doing the things (may be not wrong) but different. Discontinuity can be understood as a discontinuity in the elapsed time (offset 0x45 in the Nav packs), which is reset to zero at the beginning of each cell. This make sense to me, but as I said, I'm not completely sure...

b) "wrong/odd" values
TMAPTI points to the VOBUs multiple of "n" seconds, being "n" an integer. As you know a VOBU can have different number of frames, so, to point to the second "n", you can use the VOBU immediately before the second "n" or the one immediately after. The "best" should be to point to the one closer, in terms of frames, to your second "n", but I really think all the approaches are correct. How much is an error of one second (in fact less than a second) in the whole movie?.
VobBlanker points to the VOBU after, MuxMan seems to point to the one before.

c) Typo
"with the "TMPATI" glitch" That means "TeMPoral Advanced TImer"... :D . I'll fix the typo, thanks.

@mpucoder,
could you clarify us points a) and b) ?

EDIT: Just as an example, you can find attached the Original one, and the IFOedit, Muxman (015) and VobBlanker created IFOs
http://www.videohelp.com/~jsoto/temp/IFOs.zip

jsoto

Sir Didymus
24th January 2006, 08:53
Hi jsoto!

Well, now that MuxMan exist, we can gradually stop using IfoEdit as a reference... IMHO...

a) discontinuities - my interpretation is very simple (so it may be wrong...): if an entry in the table is the first one referring to a cell marked with the STC discontinuity flag, then the entry should be marked accordingly...

b) values in the table - instead of counting the frames, the VOBU End PTM value should be used as a reference. Here is some info on the matter "elaborated" from the philips verifier manual (I know the profiler is faulty on many checks, but here we discuss about the method...).


Each individual entry in the table contains the start address of the VOBU
where the presentation time corresponding to the map entry is reached.

Determination of the correctedness of the map entry values is done by
calculating the time elapsed since the start of the PGC:

Total_Previous_Cell_Time - Cell_Start_Time + VOBU_End_Ptm (in 90 KHz ticks)

The value is compared to the calculated elapsed time for the current
map entry:

MAP_EN * TMU * 90000 (still in 90 KHz ticks)

When the elapsed time in the PGC exceeds the elapsed time for the map
entry, then the Start Address of the current VOBU is the address to place in
the table.


c) typo - :)

Yes, hope mpucoder could clarify...

jsoto
24th January 2006, 09:58
Well, now that MuxMan exist, we can gradually stop using IfoEdit as a reference... IMHO...
Agree..., but I like to dig into the differences... In example,
- lately (working in pgcDemux) I've found a bug in IFOEdit (never saw an effect in a settop). It counts the number of ac3 frame headers just looking for 0x0b77, and this pattern can be reproduced inside the ac3 frame, giving an incorrect number of headers..
- I've did some binary comparations in VobBlanker SYNCI pointers adjustments versus Muxman, and I found some really minor differences (Muxman was correct here, as usual) that I've fixed in last VB release.

a) discontinuities - my interpretation was very simple: if an entry in the table is the first one referring to a cell marked with the SCR discontiuty flag, then the entry should be marked accordingly... Disagree. See some originals. All the ones I look into mark the last entry of each cell as discontinuous, inside a continuous VOB and also in a seamless VOB joint

b) values in the table - instead of counting the frames, the VOBU End PTM value should be used as a reference. Here is some info on the matter "elaborated" from the philips verifier manual (I know the profiler is faulty on many checks, but here we discuss about the method...). It is exactly the same in the VOB is well authored. (Not sure if there are some stills, but this is not the case). In fact, what VBlanker does is trust the elapsed time and may be I should add the number of frames (taken from VOBU_End_Ptm and VOBU_start_Ptm ) to see if the VOBU exceeds the point. In other words, I'm using the starting time of the VOBU to compare with the TMAP entry, and seems the ending time of the VOBU is the one that should be used.

When the elapsed time in the PGC exceeds the elapsed time for the map entry, then the Start Address of the current VOBU is the address to place in
the table.

In any case, we are discussing about less than one second... I do not believe anyone will be able to notice that ...

jsoto

mpucoder
24th January 2006, 10:16
Different authoring programs treat the time value and discontinuous flag differently. There is a thread somewhere where we tried to determine the true meaning of the flag.
NTSC drives the verifier crazy (to be expected, it was written in a PAL country), and the time map is no exception. The verifier wants one second to be 90000 ticks, but the cell elapsed time works on a 90090 tick second (30 frames * 3003). The same is true for the sri pointers. Scenarist uses elapsed time, Muxman uses 90000.

Sir Didymus
24th January 2006, 11:29
In any case, we are discussing about less than one second... I do not believe anyone will be able to notice that ...


I see, I see. Now that you are explaining, I see the "wrong values" I was noticing are infact just differences of exactely of a single VOBU... :rolleyes:

Sorry for raising the whole argument...

@mpucoder

:thanks: for the clarification...

I still wonder which way the standalones are using this table...
Is it just the entry table for time search functions ?

jsoto
24th January 2006, 12:18
http://forum.doom9.org/showthread.php?p=649344#post649344
As you can see, I have some memory lacks.....

jsoto

Sir Didymus
24th January 2006, 13:02
Wow... :)

Very nice and useful reading...
Many thanks.

yoy
26th January 2006, 00:04
I have been using the great VobBlanker program to blank out logo, etc because the program is so easy to use. I experienced a problem when I use it lately to manually blank 2 logos in VTS_01_*.VOB with the following message when VobBlanker finished Processing:

Warning: nuPGCs higher than the value stored in VTS_TMAPTI2
nuPGCs higher than the value stored in VTS_TMAPTI3

The resultant files when input to DVDShrink has the following error message
"Invalid DVD navigation structure" and "Overlapped I/O operation is in progress". The resultant files however can be played by WinDVD but cause VobBlanker to abort when input again to VobBlanker.

Next instead of manually blanking the 2 logos, I check on the mark in "blanks cells without buttons" and got the same warnings and problems again. I tried to use the older versions of VobBlanker and got the same errors. Any one can help?

jsoto
26th January 2006, 01:32
The Warning means that the number of PGCs in Titles domain (the ones you see in the bottom part of main VobBlanker dialog) is higher that the number of PGCs in VTS_TMAP, This is not legit, because VTS_TMAP must have the same number of PGCs.
But it is only a warning, I do not know critical side effects (only problems with navigation sliders, etc)
In any case, nothing to do with menus.

You get two error messages (instead of one) due the code is not clever enough, and issues a warning per PGC which number is higher (PGC # 1 is OK, but PGC# 2 and # 3 output an error)

You can send me the IFOs, I'll take a look, but I'm pretty sure you have wrong IFOs...
jesus_soto_viso at terra dot es

jsoto

jsoto
26th January 2006, 01:39
Received by mail from Tony
I have been using your previous version to the current 2.1.0.0 with much success, however, now that I have downloaded 2.1.0.0, I am unable to get the program to run. I tried downloading again from Doom9 with no help. The program seems to be all there when I extract all files, yet when I request it to run, the processing window will not appear.

I usually answer the mails, although I prefer to answer in a post, so the answer can be shared by the community, and saves me to repeat it...

But in this case I'm unable to answer by mail, Tony's mail server is rejecting my answers (seems my mail server is blacklisted...), so here is the answer:

wrote by myself, trying to answer by mail

Well, I need more info..., but trying to guess...
Look into your task manager. Is VobBlanker running? If yes, be sure you kill all instances. May be a reboot can help..
Execute the registry cleaner delivered with the exe. I've found problems with initial window coordinates corruption, which are stored in the registry (main window is out of the screen)
Let me know if this works.
BTW, which is your OS? MS-Windows-XP? W98SE? Linux?


jsoto

wmansir
26th January 2006, 05:39
I've had this error reoccur a few times. When saving a project file the program does not save all the parameters. Usually I don't notice unless it's the input path and the project cannot be loaded. It seems the [General] section often is composed of just 2 or 3 lines instead of the normal 10 or so.

If it matters my input path is usually on the E,F or G drive, but since I only work on one project at a time I always save the project to E:\VobBlanker.ini and overwrite the existing file there. This is an intermittent error, as I recall save/loading project files recently, but the error is very common on my machine. I haven't noticed any trend to suggest what is causing it.

I tried to recreate one of these bad .ini files, but of course it won't do it now. I'll post it the next time I encounter one. Earlier I had one, but when I clicked "Save" instead of "Save As" it overwrote it with a good .ini.

jsoto
26th January 2006, 14:27
Yes, I've also (occasionally) seen this ini files w/o the first lines... Don't know the reason, and dificult to reproduce....
Seems related with the OS caching... I'm deleting the file before writing it. It's much more faster. May be it will be better (and safer) to don't delete the file....

jsoto

jeanl
27th January 2006, 17:36
jsoto, try using fflush() after every time you use fprintf() or fwrite()... This flushes the buffer... Maybe that will help...
jeanl

jsoto
28th January 2006, 02:53
I think it won't help...but I'll test it, after the deletion and after each write...

I'm deleting the file and after writing the file with WritePrivateProfile in order, starting from the first line...
The lines lost are the first ones.... Seems as the file deletion is "delayed", so the file is deleted after writing the first lines...

The reason to delete the file is that WritePrivateProfile is much faster if the key you are writing is not present in the file.

jsoto

JFerguson
29th January 2006, 19:54
Are the Process Titles and/or Process Menus ticks saved with a project? I'm seeing them reset after loading projects...

jsoto
29th January 2006, 22:40
Yes, they are saved correctly, you can verify it in the file...
but it is also true there is a bug loading Process Titles , so it is not loaded and is reset to your default value (the one stored in the Registry).

jsoto

jsoto
1st February 2006, 01:37
I experienced a problem when I use it lately to manually blank 2 logos in VTS_01_*.VOB with the following message when VobBlanker finished Processing:

Warning: nuPGCs higher than the value stored in VTS_TMAPTI2
nuPGCs higher than the value stored in VTS_TMAPTI3

The resultant files when input to DVDShrink has the following error message
"Invalid DVD navigation structure" and "Overlapped I/O operation is in progress". The resultant files however can be played by WinDVD but cause VobBlanker to abort when input again to VobBlanker.

Well, I got the IFOs and found the problem. VobBlanker doesn't calculate correctly the last useable byte in TMAP of PGC1, (because PGC2 does not exist and it has to). So it uses more bytes than the ones reserved for TMAP, overwritting the next sector (VTSM_C_ADC). The result is a very corrupted IFO.

I fixed the bug, but because this is a very rare situation (you need a bad IFO to reproduce it) I won't release a bugfix. But, for sure, it will be fixed in the next version.

jsoto

tllk
2nd February 2006, 19:45
When I use VobBlanker 2.1.0.0 to replace PCG

PCG1 VID/CID → PCG1 VID/CID
01/01 01/01
01/02 02/01
01/03 02/02
01/04 02/03
01/05 03/01

Although success to become

PCG1 VID/CID
01/01
02/01
02/02
02/03
03/01

But my DVD Player can't pass VID to another VID,
Use DvdReMake Pro to check,Export DVD will become to
PCG1 VID/CID
01/01
01/02
01/03
01/04
01/05

Is it a bug ?

jsoto
2nd February 2006, 20:20
PCG1 VID/CID → PCG1 VID/CID
01/01 01/01
01/02 02/01
01/03 02/02
01/04 02/03
01/05 03/01


Do you mean the original IFO (the one you load in VobBlanker ) is the left column (only VID=1) and the final product has 3 different VIDs? If this is the case, yes this is a bug (I never saw it).
But not if the replacing PGC is the left column and the original and final PGCs have 3 different VIDs.

In any case, please zip the IFOs (all IFOs, please) before (originals) and after, the project file and vobblanker's log file and send them to me.

jsoto

tllk
3rd February 2006, 01:16
Do you mean the original IFO (the one you load in VobBlanker ) is the left column (only VID=1) and the final product has 3 different VIDs? If this is the case, yes this is a bug (I never saw it).
But not if the replacing PGC is the left column and the original and final PGCs have 3 different VIDs.

In any case, please zip the IFOs (all IFOs, please) before (originals) and after, the project file and vobblanker's log file and send them to me.

jsoto

I mean

(A) become to (B)

Sure,use VobBlanker (A) must the same (B)

(C) is a new PCG that I make to replace a part of (A)

*
(A) (B) one PCG multi VID (total 5 cell)

(C) one PCG one VID (total 5 cell)

(B) some DVD Player can't work well in change VID,but original (A) have not
this problem.

tllk
3rd February 2006, 08:01
(A) use DVD remake pro Export DVD,all ifo the same (A)
(B) use DVD remake pro Export DVD,part of ifo become (C)

If I take (A)'s ifo with (B)'s VOB,use DVD remake pro Export DVD will part of ifo become (C).
If take (A)'s VOB with (B)'s ifo,use DVD remake pro Export DVD,all ifo the same (A)

So I guess it must VOB's VID something worng.

tllk
3rd February 2006, 08:11
(A)
http://tllkjp.hp.infoseek.co.jp/date/A.rar

(B)
http://tllkjp.hp.infoseek.co.jp/date/B.rar

(C)
http://tllkjp.hp.infoseek.co.jp/date/C.rar

jsoto
3rd February 2006, 10:43
At first view the IFOs (B) are OK. Trusting the IFOs the original PGC is seamless-joined in the VID changes (this can be checked looking into the a/v delay, with pgcDemux, i.e., in the cells 2/1, 3/1 and 4/1. It should be negative and different to zero.

So, what are you exactly doing? Seems you are adding a sub, but how did you make the replacing PGC (C)? Did you use pgcDemux+MuxMan?

In any case to inter-change VOBs and IFOs between A and B is not a good idea....

IF the original joints aer seamless (a /v delay negative at the beginning of each VID) the DVD should work as it is, but if you want to have only one VID, youcan use VIDChanger on (B), because it was really muxed in only one VID.

Bit if the original joints are non-seamless (a/v delay=0 at the beginning of each VID), you have to demux by VOBid and remux each VID individually.

jsoto

tllk
5th February 2006, 11:51
Sorry my English too poor.
I describe more clear about my question.

If I use scenarist to create a VTS include 1 PCG,like
(VID/CID)
01/01
01/02
01/03
01/04
01/05
use VIDChanger or VOBblanker to change VID to
01/01
02/01
02/02
03/01
03/02

Then use DVD remake pro to correct,will become to
01/01
01/02
01/03
01/04
01/05

But if I use scenarist creat VTS is
01/01
02/01
02/02
03/01
03/02
use DVD remake pro to correct,will nothing happen
Although I use VIDChanger or VOBblanker to change VID any number
DVD remake pro will to judge it to original VID.

In my DVD player that use VIDChanger or VOBblanker to change VID's
will crash.So I make a guess at VIDChanger or VOBblanker to change VID
are incompletion.

jsoto
6th February 2006, 01:35
Probably DVDRemake pro is checking the internal SCR (or may be PTSs) so it is abel to detect if the scenarist created VTS is only one VID or a multi-VID VTS. Sorry, I do not have DVDRemake so I cannot check it.

A continuous PGC, made of two or more VIDs should work in your settop. I do not understand why it crashes...

In any case, you have to demux/remux by VOBID if the VOBs are non-seamless joint, as it is stated in your IFOs.

jsoto

mad-eddy
8th February 2006, 22:20
Hi.

I used today for the first time the Strip Streams function.
Question: Is it intended, which contents are removed however the Streams themselves as dummies in the VOB's to remain? Is there any a possibility let remove this dummys immediately with?

Greeting

jsoto
9th February 2006, 01:25
Hi.
I used today for the first time the Strip Streams function.
Question: Is it intended, which contents are removed however the Streams themselves as dummies in the VOB's to remain? Is there any a possibility let remove this dummys immediately with?
Greeting
The whole stream is removed. Nothing remains in the VOB in the stripped PGC. Note the stream still can be present in other PGCs in the same VTS.

But the info still can be in the IFO. You can check
"Clear audio/subs status when blanking/stripping" in More options dialog to delete the track in the PGC (be careful, some settops can have problems if the track is not the last one). Even in this case, the stream still will be referenced in the IFO (VTS stream list : VTSI_MAP), but, opening the DVD, pgcEdit will detect if the stream is not used any more in a PGC.

jsoto

jsoto
9th February 2006, 01:36
Hi all,

Here you can find a 2.1.1 beta.
http://www.videohelp.com/~jsoto/temp/VobBlanker_2110b1_exe.zip


Added: Multiple Cut. Cutting at cell level is now supported, so up to one cut per cell can be done per session.
Added: Cut cells capability in MENU domain.
Added:Added some shortcuts in Main dialog Menu
- Menu Still all PGCs with audio
- Menu Still all PGCs w/o audio
- Menu Delete all no buttons PGCs
Changed: Blank auto now keeps the PGCs with duration longer than 85% of the longest one. Useful for episodic DVDs
Changed: Using last version of DVDPreview
Changed: Disabled loading a PGC in Tiny in the case of multiple selection
Changed: Statically linked mfc42. Seems wine did not work with shared dll
Changed: Default of Autostart Tiny changed to False.
BugFix: TMAPTI Overwrites next sector in some cases of wrong input IFOs
BugFix: Loading "Process Titles" setting from project file was broken in 2.1.0.
BugFix: Setting to default values in main dialog were the old ones (not updated)


Note: Be careful with Cut feature... Cuts are not clean (audio frames are cut in the middle, etc)... Test deeply your DVDs
Also, when using Cut in Menu domain you should keep the buttons and subs part of the cell. VobBlanker does not check it.

jsoto

jeanl
9th February 2006, 01:38
Wayyyyy cooooool! Thanks jsoto! :) :)
jeanl

jsoto
9th February 2006, 01:40
Wayyyyy cooooool! Thanks jsoto! :) :)
jeanl

Bah, not too much... I'm busy (but not lazy) lately...

jsoto

jsoto
9th February 2006, 01:42
@jeanl

Changed: Using last version of DVDPreview

I do not know the version number of this ;)

jsoto

mad-eddy
9th February 2006, 02:44
@jsoto:
You can check "Clear audio/subs status when blanking/stripping" in More options dialogI had looked for that. Thanks

# Added: Multiple Cut. Cutting at cell level is now supported, so up to one cut per cell can be done per session.
# Added: Cut cells capability in MENU domain. Extremely useful for me.:cool:

Surf
12th February 2006, 03:53
Hi Jsoto! Long time no bother! :D


I see that you have made fantastic stride in improving BobBlanker(lmao, old joke). Now, there's about 5 mth left for biking, surely you can come up with frame level cutting instead of GOP's(or whatever it's called)?

jsoto
12th February 2006, 12:54
Hi Surf,

Cutting at Group Of Pictures (at VOBU level) can be easily done. Note the cuts are not clean, because audio cuts are not absolutely synchronized..

But cutting at frame level, AFAIK, needs encoding. One smart cutter can encode only the GOP being cut.... Also, the audios have to be properly cut...
As you can see, it is a very complex thing. Sorry, not in my TODO.

jsoto

jeanl
12th February 2006, 18:36
I think TMPGenc DVD Author (or one of their products) can do that (decode, cut, re-encode)... But that seems tricky to me...
jeanl

jsoto
13th February 2006, 10:53
Hi all,

Here you can find 2.1.1 beta2.
http://www.videohelp.com/~jsoto/temp/VobBlanker_2110b2_exe.zip

changelog versus beta 1

Added: Re-run is now allowed without reload the project if "Use input folder" was not checked. I've kept all the internal vars unchanged (I hope), so the re-run should work fine
BugFix: Combinations of Reusing Language Units and deleting/blanking the reused LUs did not work well
BugFix: Default of Autostart Tiny changed to False was not done in more settings dialog


jsoto

blutach
13th February 2006, 13:14
@jsoto

A lovely improvement is the multiple cuts! Is there any chance of implementing the stripping of audio in a (motion or any other) menu without making them stills? I know MenuShrink (http://jean.laroche.free.fr/MenuShrink/) can strip audio but only if you "Shrink" the VCID. I suspect VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) is the same.

Signed

Greedy Les

Regards

jsoto
13th February 2006, 13:41
Do you mean strip one audio keeping the other/s? If the menu has only one audio (as usual), stripping it has no sense to me...
The answer is yes, it is possible, but I 've more important things (IHMO) to add.

jsoto

Rockas
15th February 2006, 15:44
Hi Surf,

Cutting at Group Of Pictures (at VOBU level) can be easily done. Note the cuts are not clean, because audio cuts are not absolutely synchronized..

But cutting at frame level, AFAIK, needs encoding. One smart cutter can encode only the GOP being cut.... Also, the audios have to be properly cut...
As you can see, it is a very complex thing. Sorry, not in my TODO.

jsoto
I think TMPGenc DVD Author (or one of their products) can do that (decode, cut, re-encode)... But that seems tricky to me...
jeanl
Tell me about it... I started working on an app some time ago... it's on a stand by period :)
The cuts are "some what" easy... the hard part is on the "joins" :)
I haven't give up yet... but I'm close to it... you know... working for free is not always fun lol

Rockas
15th February 2006, 15:55
@jsoto
... by the way... there's a bug on the Cells dialog... if you make the dialog bigger... the "Abort" button remains fixed.