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?

Cool 8) :D
No problem ;-)

Yep, it seems they are identical to the source because all VOB sources on my disk produce such a message when I try to load them ;-).
Let me tell you that I have never ever tried to add a VOBfile to a DVDLab project.
Usually I only do M2Vs and AC3s and have DVDLab mux them and I never get such a message.

May very well be a DVDLab bug :!:
Have you tried using MPEG Validator to analyze your source, and then the chunks :?:
http://sr2.mytempdir.com/144314

-kwag

Or make a quick test Rui :idea:

After you chop all your pieces (I post three VOBs on the example), and assuming your original VOB is named VTS_01_2.VOB, do this on a command prompt:

copy /B VTS_01_2.VOB.kutter.1.VOB + VTS_01_2.VOB.kutter.1.VOB + VTS_01_2.VOB.kutter.1.VOB joined.vob

Now the file "joined.vob" should be an identical bit by bit to the file VTS_01_2.VOB

-kwag

Stand by.
Working on many tests to see if it has to do with the chunks or with DVDLab.
I'll be back in '5.
Cheers

I did many tests but none suited my needs.
So I went for one last and very long test.
I added 2 vobfiles with 2 full movies that I just extracted to my HDD with DVDDecrypter.
And this time there were no messages and the muxing went well from the begining until the end.
I just burnt it to a DVD-RW and it's playing fine in the living room.
So the issues that I had earlier must come from the chunks done by Kutter.
Or maybe I'm missing something...

Hmm, I just did the copy test, and the final joined VOB is identical to the source :roll:

That means there's a perfect match bit for bit between the files.
Unless the headers are buggy, and I'm not correctly tagging the cuts on the individual pieces.
I'll do more tests.

-kwag

@rds_correia & Kwag

Thanks guys for the extensive testing you have both done, I am sorry I haven't had time to test myself but I was backing up one of my DVD's

It is a shame about the 2Gb limitation of PB, I wish the developer of this programming language would fix this issuse as it holds back the excellent developers here who use it such as Karl and Andrej.

Hopefully that 64bit binary Inc supplied will come in use.

I hope to run some tests myself today. :)

About the Open GOPs in DVD-Lab, I get this notification also when adding a .mpv stream made by CCE from my DVD sources but it doesn't affect the authoring and I have no probs when I watch the backups on my SAP.

I just thought that info might come in useful. :)

When you apply this copy /b command, files are joined but headers are not rewrited, then you will have a file that plays fine but time info will be wrong. Later when you reencode a such video, a-v will be async.
It was my experience a time ago while programed a tool.
I dont know if in this case it could be important.

Edited: I worked with mpgs and not with vobs.

Did you try fc /B ?

Just let me know if I can help ;-)
Cheers

@Boulder,

I also tried the FC /B. Result
C:\kutter>fc /B joined.vob h:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
Comparing files joined.vob and H:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
FC: no differences encountered

I suspect I might have a bug in the end header on the chunks.
As a matter of fact, this has to be the problem, because the way it's suppposed to work is that each chunk is a valid MPEG file with start and end headers. So a join of all chunks shouldn't be the same as the original, because each chunk has to have added ending headers.
I'll fix this today :)

@All,
Thanks for all the feedback :!:

-kwag

You won't loose informations by cutting if encoding the mpegs using SEQ Header at every Gop. Thats normally the "default" as mpeg was also meant to be a streaming format.
And here Kutter should ONLY cut at SeqHeaders.

That header can be easely parsed as it begins using .....

I used that in Packshot and Mencalc to get the needed Stream Infos when importing mpeg2/1 Files.
The "Parser" searches in the opened file till he founds a sequence header, then do a FileSeek(Loc()-3) so you get again in front of the $B3010000 Long value and THERE you do your cuts!

If only ONE Seq Header at the beginning of the source is found then you MUST parse it completely and add it to your cutted target chunks at their very beginnings!

I Missed something:
You cant cut mpegs just by bytes! You have to cut at an I Frame startpoint.
Do look at the (if available) mpeg2schnitt sources, there you can see how its being done :)

That's exactly what I'm doing, Andrej :) It does ;) Very good code, although I already had my implementation, which is completely different :)
Actually this one you posted is a little simpler than the one I had, but if it ain't broke, don't fix it ;)

Now there's something that just came to my mind. What happens if an actual header sequence pattern shows up in the data (video) part :!:
What I mean is, in standard data communications, if a control/command pattern is part of the data, it's usualy preceded by some escape sequence.
This way, you can differentiate from actual headers or from data.
So what happens in an MPEG stream, when a header byte pattern is part of the data :?:
If it's not preceeded by some escape sequence, this can (and will!) throw off any decoder, because it thinks it's a start of a sequence header, when in fact it's actual data :roll:
Anyone ever thought about this, or did I miss something in the MPEG protocol :?:

-kwag

Man!!
I know you're probably right but I'm affraid I didn't catch up a word of what you wrote in the last paragraph :lol:.
Cheers

Don't worry about it Rui :lol:

-kwag

I do think these 4 bytes in their count are something like protected!?

Cause if not, such a parser would sometimes put out garbage - and that never happened to me.

But it CAN be a valid four bytes in a video stream, so there must be some identification bytes (escape sequence) to differentiate commands vs. data. Maybe all decoders are depending on the following couple of bytes after the start header, which are 0x2d, 0x01.
That would make the pattern 00, 00 ,01, B3, 2D, 01 much more difficult to produce in actual data, but it still CAN happen :!:

-kwag

@Rui,

Did you try importing .M2V file chunks into DVDLab :?:
I just tried importing several .M2V chunks into TMPGEnc DVD Author, and there were no errors.
The original VOB file was demuxed to .M2V with TMPGEnc tools to produce the file, which I then chopped up with Kutter.
http://www.digitalfaq.com/archives/i.../2005/09/3.png

-kwag

No Karl, unfortunately I didn't try that.
I only tried it on VOBfiles.
Today I'm encoding.
Tomorrow I may find time to test it on M2Vs ;-).
Cheers