new tool Kutter
 

Thanks for your new tool Kutter Karl it looks like a good replacement for DIKumsizer, it will come in handy to cut VOB to certain sizes when needed for samples with problematic sources.

I look forward to the GUI version when you have to time to program one.

Great work Karl and thank you. :D :bowdown: :bowdown:

Nice seeing you release new developings again! :)
Where the PB / Linux Problems solved?

Thanks Guys :D
I haven't tested the file size limitations yet. I don't recall if it was 2GB or 4GB maximum file size.
I'll have to join several VOBs and try it out.
In normal circumstances, nobody should have a problem, because most VOBs are ~1GB, and regular MPG, M1V, M2V files don't even approach 2GB.
But I'll check on that.

-kwag

I recall those problems myself Karl and we both came to the conclusion that it was 2GB.
Anyway thanks for another life-saver tool and hope you can build a GUI for it in the future.
Cheers

- 1st possible bug -
I'm trying to cut a 4GB VOBfile in chunks of 2GB but kutter says "File not found".
So I changed the filename from vts_02_1.vob to vts021.vob and now it's cuting as expected without error messages.
Could you check if the filename allows for underscores and dashes?
You see these are regularly used in filenames :lol:.
Cheers

Thanks Rui :!:
I'm not doing any filtering on file name characters, etc., so let me check what's going on :)
BTW, how's the processing speed :?:

-kwag

It works fine here, with all underscores :roll:
What is your full path :?:

-kwag

:BangHead:
Newbie alert! Newbie alert!
Forget about the name issue.
That's Kutter's way of telling the user that the file is already open in another application...
Shame on me ... I was trying to use a file that was already open by VDubMod...
So there's no filename issue.
Let's see the 2Gb issue and I'll tell you about the speed in a minute ;-).
Cheers

Ahh!, well good to know.
That's because I'm only checking (sloppy programming :lol:) for failure (any), and that's why it sais the file doesn't exist.
I should make it more robust, and detect if the file is open, locked, etc., so it has some :arrow: "Noob" protection :lol:

Thanks,
-kwag

3Gb issue still present.
I asked for "c:>kutter.exe vts_02_1.vob 2500000000".
The source is a 4.673.910.000bytes vobfile.
And Kutter gave me chunks like:
part1-2Kb
part2-680000Kb
part3-2Kb
part4-680000Kb
etc...
As for speed I'll be back in a minute.
Cheers

Took 3m20s to kut 2 slices of 1GB each.
After that it went nuts :(
This is, at the expense of very little CPU power.
Almost all was being done at the HDD.
Which BTW is a Seagate SATA drive.
Hope this feedback helps :)
Cheers big K

please try if you can use these chunks back into a DVD authoring programm and do a DVD from them.

I'm on it Phil ;-).
I'll be back in a flash :lol:.

In what way did it go nuts :?:
I just cut a 1GB piece in ten 100MB pieces, and there are no errors :!:

-kwag

Shouldn't be a problem Phil :)
Each chunk is a valid MPEG file, with correct start/end headers ;)

-kwag

The Filesize amount value is (imho) due a (still) non-support of 64bit variables. That issue is one of the most anxient in the PB area and it seems the developer fred cares more about other addings.
There's a UserLib called "f64", maybe you can use it? Even its a float based library, maybe you can do a trick via strings or whatever to parse/use longlong integers.

Otherwise do "split" the longlong input via a dummy-int64 structure?!

Here a sample found in the PB area:
Yep! 2GB = 2048MB = 2097152 Kb = 2147483648 bytes!
And that 2147483648 is exactly the maximum supported by PB as 32bit long value. So do look at the code above ;)

As VOBs should always be at max 1024MB that is no problem, BUT if a user feeds your executable using a 3GB m2v then this could be a problem.

I see.
But your source was 1Gb long.
Now take a 4.5Gb long source and try to produce 1Gb chunks.
You'll end up with two 1Gb chunks and four thousand (4000) 2Kb chuncks.
Yes, I do mean 2Kb and not 2GB.
Well some will be 2Kb other will be 100.000Kb but the vast majority will be 2Kb :(.
That's what I meant by nuts :lol:.
As for the authoring checking, as I write I'm burning a DVDLab disk with one of the produced files.
DVDLab complainted that the GOP was open and that for authoring I should set my encoder for closed GOP.
Other than that the authoring went fine.
I will play the disk and let you know how it went.
Cheers

Thanks Andrej :)
Yep. That's still a problem.
But let me look into the 64 bit library :)

@Rui,

As Andrej just mentioned, the limit is 2GB on file size (a PB limitation), so anything after that will cause weird behaviour.
I'll look into adding 64 bit file size support, and then you can feed it your whole hard drive :mrgreen:
Until then, please don't use files larger that 2GB :cool:

-kwag

That shouldn't be 8O
The chunks are identical to the source :!:
Did you try feeding the original VOB to DVDLab, and see if you get the same message :?:

-kwag

Wait a minute :!:
I was adding 2 x 500.000KB chunks and 1 x 350.000KB chunk in DVDLab and after the DVD was out I took it to the SAP and there is only 1 chunk available for playing.
So I restarted the authoring and after it finished I could see two "MSG: 2963" on DVDLab's log.

@Phil
Do you know what that means, Phil?
Because I went to see what it has authored and again there is only 1 chunk available for playing :?
Could this be a DVDLab vs Noob problem at 1h38am :?: :lol:
Or is DVDLab having difficulty in accepting the chunks?