MTR 6 ANNOUNCEMENTS - READ FIRST!

[geezerbuttz]

This morning was one of those days that you say "oh my god".

Why?

Well , in days of past , we used to be able to expose bindings in our custom classes. Jolly old Apple thought in thier wisdom to remove that from us , it was clearly far to usefull.

So , If you wanted a blank canvas to design on , you use NSView , and that has pretty much only enabled and visible bindings available.

So , all the flags I just coded were done and hooked into the tableview row redraw.

Then I thought , why can I not subclass an existing control , with similar functionally in bindings that I need , and hook my drawing routines into it.?

So I did , NSProgressIndicator fitted the bill. I needed to cast a few values back and forth , but low and behold , the flags code for the cell table fitted and work perfectly when bounds.
Of course you need to prep the data your passing into it if you need to pack the data ( more than one value passed in the binding ) but its ok as long as you keep on top and document the class.

Hardest and stupidest part was setting the control size. Most Appkit classes are a fixed size , or scalable in one dimension , but it the end , constraints will allow you to resize them as you need.

All redone , and bound to the ObjectValue from the arrayControllers that are bound to the table views.
works a treat!

Still not to old to learn something new.

[geezerbuttz]

well we are just about done with 6001.

Been working in SectorScan to fix one last niggle.

Progress bars...

They simply did not have enough resolution to display possible defective sectors...

I have coded a new indicator , the has 4 rows of 50 tiles ( 2x resolution of standard indicator) with some internals that make sure defective blocks are always shown

Its timer driven , providing a smooth constant experience.
Verification uses the same UIObject now.

Need to run a few disks to ckear up an issue ( well im not sure its an issue as I have not been able to reproduce it now )
Than I can package a new istaller for all.

[geezerbuttz]

right , reverted back to event driven....

On slow drives there were far too many redraws that did nothing.

I added some extra hooks into the main code ( actually block properties ) and populated them with the code to call the new progress indicator..

Did I ever say how much I love blocks ?

Anyway , just wrapping up now... Still have to test on 10.11 tomorrow.
G

[geezerbuttz]

right , settled on everything now , got the resolution of the display up to 1400 ish .. plenty of real-estate to capture the smallest issues.


Testing tomorrow ( said that before )


G

[geezerbuttz]

well , here we go with back porting to get it fully working in 10.11

So far its is not good news ...

Im installing some older OS 10.13, 10.14 etc to see where the rot sets in , but its mostly tableview implementation not redrawing correctly at all....

These are bound to an array controllers , so not much I can do with dodgy bindings in older OS....

Custom objects do not draw in the view that they are implemented in..... huh?
This will take a little while to sort iut and I may have to make some concessions to get it stable...
Hope not of course , I will do my best.

[geezerbuttz]

A busy Sunday.

Well 90% of the issues are corrected , the deal breakers are done , and the app runs now in 10.11
I still need to sort out three graphical issues , but that can be done in the morning.

UI performance , even virtualised , is far better than it was on the older releases.

From 10.14 onwards there are no issues.
G

[geezerbuttz]

well , yesterday was a real senior moment.

Spent the whole day in the requant engine... looking for a bug the stopped the requant engine , locking it up before the process had completed.

A whole day , only to remember right at the end "did I sign the code?"

No.

Stupid.

Idiot.

Fill in any gaps that may seem appropriate.

Anyway , today I changed all the older legacy methods in the requant engine , improving how we feed data into the requant engine.

Instead of polling for process end, we now rely on signalling across threads ( hello blocks ) , not only that the buffering of data in the requant thread is far less expensive on cpu time. I adopted a multi packet array stack rather than feeding and altering one large data block.

It is quicker to simply add a new block onto the stack than to manipulate a data object.

Changed all thread locking to improve coherency.

All this has one visible user change ( so far ) that at the end , the array stack has to be purged before completion , thus on quit or end ,it takes a few seconds longer to exit.

This being said , and with the discussion in another thread , now may be the time to move the RQEngine into a framework....
It may take a couple of days , as it is quite complex , but that gives us portability.

Stay tuned.

[geezerbuttz]

Requant is now a framework.
A few updates into the code that keeps track of disk structure for DVD rebuilding in MF.

That will also get moved eventually.

Need to test this framework right now.

[geezerbuttz]

Back in DVDSectorProbe...

I realised that while we are getting all the sectors that are played , I was not getting all the program chains that are accessed.

Some PGC's get accessed , but jump out , playing no video. As no video is played , we do not reference them.
The addition Im working on will store all accessed PGC's that are read during playback.

This addition will change nothing currently as it is only to be used in the rebuilder slated for later this year.
Your existing files will still load , but if you intend to use the rebuilder , you will need to generate new maps.

( we can prune out unused PGC from the IFO reducing some bloat)

MTR will warn you in this case.

[geezerbuttz]

Sorry if im quiet for the last few days.
I am busy implementing something I planned to do , but found ut rather hard as Apple has let the documentation fall into posterity.

i.e , there is virtually no documentation past 2005.
There is nothing on Apples site now , nothing in the dev docs , nada , zilch.....

Managing to get most of it working , but the last part is a bit of a pain.

Stay tuned.
G

[geezerbuttz]

when running tests i found a new issue in the MFRebuilder. The root ifo had nmr of vts set to 0.
this way you could not load a MF disk back into mtr rebuilder as it would not pass validity.

Who knows why I missed that.

[geezerbuttz]

ok , an issue has arisen where the dvd VTSI rebuilder simply failed to update the ifo..
Need to fix that.

[geezerbuttz]

intersting observation:

I extracted a MF to a rebuild disk. I checked it it was fine , I burned it to a disk , it was fine.

I go to bed , wake up test the VTS Folder , and it is no longer fine. Iso burned from it is fine.

Repeated the extraction , and repeated the whole process.
Everything was fine , until , over night the video TS folder became corrupt.
Well not corrupt , but the sectors info in the Video_TS.ifo no longer matched the disks layout.

This does not effect ISO extractions as they have a self contained filesystem.

Seems the mac is moving files around , thus altering the the offsets that have been set in the disk file structure needed to create a working disk.

I tried to lock the files , but it made no difference....

I may need to code a check to rebuild the structure if I cannot find why this is happening.

[geezerbuttz]

bit of a discovery this morning...

I discovered how to 'make' one of these disks that replicate the file structure multiple times.

Simple hardlinks.

The nice part comes that , when you create an ISO of the structure the hard links are maintained.
This is how we have VIDEO_TS folders of 70GB but an ISO of 8Gb.

So... break down the structure as MTR does , re quant the available located data , rebuild the missing file structure with hardlinks , update Ifos/bup , create ISO.

This way , bloated disk , can be reduced to 4.3Gb and maintain the original structure....

Just a thought.

If your on a unix based system ( who isnt ) you can use softlinks in the OS ( VIDEO_TS folder )to replace the hardlinks.
DVDPlayers in OS's do not use the file pointers or offsets in the ifo ( well most dont ) so no need for hardlinks.....
That way the on disk folder comes back to 8Gb

The only drawback to the hardlinks is that when creating the final folder , you do need more available space to store the expanded data.
G

[geezerbuttz]

Well , it has all been very quiet lately as I have been busy getting up to speed with some new frameworks.

To cut it short.

Im moving the new parts of the UI over to a more mac centric approach. UI code ( in development project) has been completed ) I now need to move it across , gut the older UI code , and interface the two together,

This of course is for the new utilities menu , and its enclosed fucntion .
Not telling you what they are yet,

Anyway , im away ... forst time since my folks passed last year , for two weeks.
So It will be quiet again for that period.

Taking the MBA with me so , no reason to get bored.

On a side note...
Im down sizing my camera kit this year , not for the money , but I just find it more or a chore carrying a DSLR around these days , so Im going for a Sony a6700.

If anybody is interested , I have for sale a Nikon D750 with low shutter count and an assortment of lenses.
All original boxes and paperwork.

Let me know privately if you want more details.

See you all soon.

[geezerbuttz]

Back in the fold at long last.
Have a three week period to get the code I wrote transplanted into MTR.

The thing about going away is that you loose track of where you were.

So... it will take a few days to get up to speed ..

I have processed all outstanding licenes.

For the delay I must apologise. I forgot to update on my MBA the license server info .
I simply could not issue a single license.
Once again . I am sorry for this.

More soon folks.

[geezerbuttz]

Hurray!

I finally managed to get it all back together , now I have to do some little tweaks here and there that arose during testing..

Soooon!

[geezerbuttz]

Been sick for a few days... back on my feet now.

A few changes happened.

All Extra apps are now grouped behind the same paywall as DVDSP and DVDSS.
All current users are golden as your license for those is permanent.

All new users will now be charged 15.99CHF due to the increased number of extra utilities present.

These now include:

ISO Encryptor and Packer/Unpacker.
A comprehensive inbuilt disk burning solution.( capable of burning most formats , DVD images , VIDEO_TS folder, audio disks , mp3 disks etc )

It can also create ISO images from a VIDEO_TS folder of your choice.

( I got so fed up with toast)

These are activated with your current Extras license , or when you purchase a license.

In line with the name change , the main menu now has changed to read "Activate MTR Extras"

All is good in 10.11 , i just need to install latest OS and test on that....
G

[TheSystemHasFailed]

ISO Encryptor and Packer/Unpacker.
A comprehensive inbuilt disk burning solution.( capable of burning most formats , DVD images , VIDEO_TS folder, audio disks , mp3 disks etc )

It can also create ISO images from a VIDEO_TS folder of your choice.

( I got so fed up with toast)

Oh WOW.. that is HUGE..! I stopped using Toast ages ago (because garbage). I cannot wait to try that!

[geezerbuttz]

Just got to solve a UI issue where some constraints are breaking...

I hate when that happens..

The app is fine , but I cant say if the UI will be fine in futureOS releases so I need to fix it.

G

[geezerbuttz]

Update is online:

New users request as normal for full installer.

Existing users can use update to download full installer to the desktop for installation.
As per the download warning , make sure you have given MTR fulldisk access before starting.

The installer will create a folder called MTR 6001 in Applications folder for you , thus not removing version 6.000
All apps are updated on this release.

From this day , a utility license now cost 15.99 CHF ( swiss money )
I accept no other currency now.

Enjoy.

[geezerbuttz]

Next release , will include the added full disk Requant application.

I have to rethink the requant code for that though , as current only handles once instace.

More to think off.

[geezerbuttz]

Well , i am back home , for a while.

Im pondering on the full disk requant code:

There are quite a few things to think about , and i do not want to write code until I get ideas to resolve them.

The main issue is the disks with duplicate sectors ... How to requant them?

I know that we can replicate the layout of such disks using hard symlinks.
The disks work fine in soft players.
This cannot work with Hard Players. So can we write an ISO to follow the symlinks , thus replicating the protection
But reducing the disk size?

Questions , questions , questions...

The first thing I am going to do is to create a replicate sector disk , and see just how to replicate that in ISO Builder.
I know it can follow links , so....

More to follow when I get my old brain around it.

( BTW this would alow you to requant those masive disks back into a reduced ISO for burning.)

[geezerbuttz]

Hi All ... Im back.

New mac , New storage devices etc.
You know how it all goes.

So im currently on 15.7.1.
This means that at this OS the last lowest OS I can build for now is 10.13 ( seems its undocumented in Xcode , but it can be done , tested )

So that sets the next release entry level.

Regarding next release.

It will be a plug in:
It will be the requant engine to replace DVD2One.

The issue here is how to deal with the disks that have replicated sectors in the file table.
With that in mind , my first study is to write code that allows me to manipulate the ISO9660/UDF file table in and ISO without rebuiding the ISO.

Tall order , but not ompossible.

Lets think about this.... if we can isolate the valid data , record the duplicate addresses , requant the valid data , adjust the filetable to point to the new correct locations ( update the duplicate file pointers ) , we should be able to rebuild a full disk , with manipulated FS , and mimic the original layout , thus defeating any and all VM playback traps.

I did a test on the mac on one of these disks... i extracted all valid data , but made hard links to the file table sectors that were duplicated , and it worked.

this only works on disks that duplicate existing entries , and not create new entries that span partial files of course.

You cannot create an ISO from such a layout , as the Mac resolves the hardlinks to real files , bloating the ISO..

Hence insitu manipulation.

So , lot of new development is required, but as a side effect , the ISO FS manipulator if it is good , I will release as a stand alone app for those who want to fiddle.....

Time period... who knows , I start on Monday.

[geezerbuttz]

Right , change of plan.

As I have been doing more rips of Episodes or Movies , and transcoding via HB , I have decided to invest my time currently on adding a X264 - X265 videotoolbox encoding chain.

As im now forced to use 10.13 minimum , I can implement the decode/encode chain.
I plan to add this to MF/Episode mode , and implement it to be used with the MKV routine.

So Instead of a MKV with MPV , it will contain the X264/5 encode.

With modern hardware and the Videotoolbox , encoding speed should not impact performance at all.

Im already doing all the ness heavy lifting , its just a matter of passing the ES packet to the decode/encode routine and write it out.

I will create a entry in prefs to handle the type of encode and the CQ of the stream.
In my experience a CQ of 60-70 presents a good performance/quality.

The Requant App will be continued afterwards.

Im on it now.

[geezerbuttz]

Just to further the last point.
Its clear that we can replace the preview code with low level toolbox decoding.

Get it off the cpu onto the hardware.

If we use CoreImage ( video ) to display the frames , we should be able to get a good performance boost.

Its all in hand.

[geezerbuttz]

Good evening all.

On hold for the current time as it seems 26,2 gave a few issues.

I have completed the debug and got it up and running again, but it did reveal a slew of issues in memory handling.

Im not going to go into detail , but I was addressing memory outside of the apps reserved area , trashing stored registers.
I fixed that , I fixed a UI issue in 26,2.

I have been coding a complete new class that handles dynamic memory allocations and deallocations to get away from fixed memory allocations. It will play much nicer with memory constraints.

That is coming along nicely.

I have accelerated the reading of obfuscated disks by nearly 500% in MF mode.


Video ( x265 etc ) is on hold while I get this large bug fix completed.
Stay Frosty.

[geezerbuttz]

Good afternoon.

Nearly all fixes and updates are done.
Did a little bit more than i intended to do.

After initial title reading speedup , i re-coded the whole reader to be multi threaded.
This mean that the total time building the titles table will be based on the number of core/threads you have and how the system distributes the threads.

I shift 24 titles at a time not even saturating the cores.

It reduces the time to build title maps.
It was a pain to do. ( no objC methods can be called from the GCD thread block , so had to rewrite all methods in pure c with no shared variables ).

Moved onto the RCE code , another area that would benefit on a multi threaded approach.
Done: All RCE VTS load in together ( cannot thread drive reads , well you can with locks , but that defeats the whole point) and then process nearly all at the same time.

That benefits all engines.

I have run this on the debug with full thread optimisations and checks.. We have Zero race conditions.

Tomorrow I need to look at a couple of UI issues ... then I can test it on 26,2 to make sure its stable.

Stay tuned.

[geezerbuttz]

Evening.
I optimised the front end root structure code.
I removed all the separate Array data stores , and did what I kept putting off , coded a object that can handle all at root level.

This simplifies code calls to the root disk structures , and does speed up further the initial data generation.


Tomorrow , i need to go into the ISO builder as I noticed it is slowing down on the disks with multiple dummy PGC etc..
( same as title was )

This disk has 3600 PGC , each with 600 cells.. They are nearly all copies , so I just need to code a way to ident the copies like I did in title. ( 2160000 iterations alone )

More soon.

[geezerbuttz]

Hello.

Reality.

So , I have been working on ISO images to gauge the speed of the structure rebuild.
The latest update to the ISo code , improves the rebuild speed nicely on disks with corrupted or bloated file structures.

But the reality is this , while on ISO the rebuild has gone form 35 seconds to approx 1 second, in real world testing , it is still drive dependent.

For example , on the initial read , ( not device mounting, that on the OS ) we do not use the disks file table as it normally is corrupted.
So we walk the disk and build our own table ( an idea here is to have the new data offsets we calculated written to the ISO image to update the file table , I will see ). Anyway , if a BUP or IFO is not where it should be ( as indicated in the file structure ) we still have to walk about looking for it. That can take time , and is vital that we find all we can.

RCE checking is almost instantaneous now , but the loading of all the IFO data still is drive dependent. ( i will look to see if we can cache the IFO reads from earlier to decrease this time gap.

Title building is also faster due to the new code , but again , IFO reading still is drive dependent.

I will be cleaning the code base over the next few days before dropping a installer.