New Tool Kutter

Zyphon · #1 09-03-2005, 04:22 PM

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.

incredible · #2 09-03-2005, 04:56 PM

Nice seeing you release new developings again!

Where the PB / Linux Problems solved?

kwag · #3 09-03-2005, 05:04 PM

Quote:

Originally Posted by incredible

Nice seeing you release new developings again!

Where the PB / Linux Problems solved?

Thanks Guys

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

rds_correia · #4 09-03-2005, 05:39 PM

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

rds_correia · #5 09-03-2005, 05:55 PM

- 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

.
Cheers

kwag · #6 09-03-2005, 05:58 PM

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

kwag · #7 09-03-2005, 06:04 PM

It works fine here, with all underscores

What is your full path

-kwag

rds_correia · #8 09-03-2005, 06:09 PM

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

kwag · #9 09-03-2005, 06:13 PM

Ahh!, well good to know.
That's because I'm only checking (sloppy programming

) 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

"Noob" protection

Thanks,
-kwag

rds_correia · #10 09-03-2005, 06:21 PM

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

rds_correia · #11 09-03-2005, 06:31 PM

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

Dialhot · #12 09-03-2005, 06:37 PM

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

rds_correia · #13 09-03-2005, 06:47 PM

I'm on it Phil

.
I'll be back in a flash

.

kwag · #14 09-03-2005, 06:56 PM

Quote:

Originally Posted by rds_correia

Took 3m20s to kut 2 slices of 1GB each.
After that it went nuts

In what way did it go nuts

I just cut a 1GB piece in ten 100MB pieces, and there are no errors

Code:

Processing file: h:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB

Split size ~100000000 Bytes.

Allocating input buffer memory.... Done.

65536000 bytes allocated for input buffer.

Now reading data into buffer...
Splitting source file of 65536000 bytes.
File VTS_01_2.VOB.kutter.1.VOB written.
File VTS_01_2.VOB.kutter.2.VOB written.
File VTS_01_2.VOB.kutter.3.VOB written.
File VTS_01_2.VOB.kutter.4.VOB written.
File VTS_01_2.VOB.kutter.5.VOB written.
File VTS_01_2.VOB.kutter.6.VOB written.
File VTS_01_2.VOB.kutter.7.VOB written.
File VTS_01_2.VOB.kutter.8.VOB written.
File VTS_01_2.VOB.kutter.9.VOB written.
File VTS_01_2.VOB.kutter.10.VOB written.
File VTS_01_2.VOB.kutter.11.VOB written.

Process completed in 150 seconds.
Total bytes processed: 1073739776
Kutter! has finished.

-kwag

kwag · #15 09-03-2005, 07:00 PM

Quote:

Originally Posted by Dialhot

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

Shouldn't be a problem Phil

Each chunk is a valid MPEG file, with correct start/end headers

-kwag

incredible · #16 09-03-2005, 07:12 PM

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:

Code:

Structure int64
  Long1.l
  Long2.l
EndStructure

drive$ = "A:\"

; this prevents the 'please insert drive' requester.
; GetDiskFreeSpaceEx_() will just return 0 if the drive is not avaiable,
; without a prompt to the user:
SetErrorMode_(#SEM_FAILCRITICALERRORS)
                                       

If GetDiskFreeSpaceEx_(@drive$, BytesFreeToCaller.int64, TotalBytes.int64, TotalFreeBytes.int64) = 0
  MessageRequester("","Drive not ready!",0)
  End
EndIf

; reset the error behaviour
SetErrorMode_(0)

; calculate sizes in mb.
TotalMB = ((TotalBytes\Long1 >> 20) & $FFF) | (TotalBytes\Long2 << 12)
FreeMB = ((TotalFreeBytes\Long1 >> 20) & $FFF) | (TotalFreeBytes\Long2 << 12)

Debug "Disk: "+drive$
Debug "Size: "+Str(TotalMB)+" Mb"
Debug "Free: "+Str(FreeMB)+" Mb"

End

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.

rds_correia · #17 09-03-2005, 07:16 PM

Quote:

Originally Posted by kwag

In what way did it go nuts

I just cut a 1GB piece in ten 100MB pieces, and there are no errors

-kwag

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

.
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

kwag · #18 09-03-2005, 07:36 PM

Quote:

Originally Posted by incredible

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.

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

Until then, please don't use files larger that 2GB

-kwag

kwag · #19 09-03-2005, 07:38 PM

Quote:

Originally Posted by rds_correia

DVDLab complainted that the GOP was open and that for authoring I should set my encoder for closed GOP.

That shouldn't be

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

rds_correia · #20 09-03-2005, 07:40 PM

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

Or is DVDLab having difficulty in accepting the chunks?