Some tools for Ogg Media files

[Suiryc]

You mean precise the language of the audio/subtitle stream, or the title of the clip ?

If so presently the only solution is to use a .omx file (same as OggMux).

So for example the commandline would be
OGMuxer -s C:\MySetupFile.omx
The omx file must contain the complete path of the files you want to include (unless all files are in the same directory).

[meleth]

ahh ok cool.. one question about the omx file. When adding more than 1 soundtrack should it look like this?

<soundtracks>
blah.mp3
English
blah2.mp3
Swahili
</soundtracks>

Edit: Oh yeah, what will happend if you tell it to split on a frame that's now a keyframe? Will it take the previous or the next one? or will it simply not work?

[Suiryc]

Originally posted by meleth
<soundtracks>
blah.mp3
English
blah2.mp3
Swahili
</soundtracks>
Yes :)

Edit: Oh yeah, what will happen if you tell it to split on a frame that's not a keyframe? Will it take the previous or the next one? or will it simply not work?
If I remember well (normally it should also be in the .txt file that comes with OGMuxer), this is the nearest previous key-frame that is chosen (it is the current frame if it is already a key-frame).

Well this apply when splitting. If you cut a part then your part will end on the frame you chosen.
The exception is if you want to cut multiple parts at a time and that the frames you specified are too near :
So if you want to keep frames 0->200 and then frames 250->500, if there is a keyframe at 210, you will get frames 0->200 and 210->500, but if the keyframe is only at 198, then you get frames 0->198 and 198->500

[meleth]

ok cool thanks.

[AmiRage]

Hi Suiryc!

I think there's a small bug concerning the ogm title naming.

The titles of the two ogm files I just created using OGMuxer 1.0a6 and an omx file are "(omx file title) - Part 1 - Part 1" and "(omx file title) - Part 1 - Part 2".

[Suiryc]

Thanks (I saw this too a few hours ago).

I will put version 1.0a7 online soon ...
Done

[meleth]

Hi, I get this ere when trying to use an omx file. Now i've tried with both current and absolute path but it doesn't seem to help. The filenames are correctly spelled, it's been doublechecked quite some times now:P

Error in InputFile::InputFile (InputFile.cpp) @ 63 : Could not open the file []
Error in InputFile::InputFile (InputFile.cpp) @ 64 : Process aborted due to previous error

Any ideas? The omx file looks like this.

<movie>
slayers1.avi
</movie>

<title>
Slayers
</title>

<soundtracks>
eng.mp3
English
jap.mp3
Japanese
</soundtracks>

<subtitles>
slayers.srt
</subtitles>

<target>
slayers.avi
</target>

<split>
0
</split>

[Suiryc]

Hi

I think <subtitles>
slayers.srt
</subtitles>
should be<subtitles>
slayers.srt
English
</subtitles>
(language of the subtitle lacks)
:)

[meleth]

k, i'm retarded for not seeing that.

[Suiryc]

:p
... and I think it is better to change<target>
slayers.avi
</target>
to<target>
slayers.ogm
</target>
(or change the extension of the resulting file if you already muxed)
:)

[AmiRage]

I'm (again) desperately trying to cut some small sample out of a 800 megs OGM file using OGMCutter 1.0a1.

ogmcutter -f "1950 2200 50000 50250" "[filename]"

The processing of the input file is passed without any problem, but when the cutting process reaches this small part OGMCuttter eats all the cpu time and a largely increasing amount of memory (180 megs plus).

Any idea?

Update: Some info about the file: It's an OGM containing an XviD video and two OGG audio streams, two subtitles and chapter info.

[Suiryc]

Again with those small samples ... :)

Did you tried with OGMuxer too ? (you can cut the ogm file with it ... this is a specal case since there is only one input file but it should work too)

For the memory I know where it comes from : if there is something wrong (a bug of course ;)) that prevent the tool for getting enough information to write to the file, then it will process the rest of the input file ... in memory (fortunately this cannot happen except if there is a bug :p ).

Now to know where is this bug, this is another thing. I will make some tests to see if I can reproduce that.

[AmiRage]

It's the same using OGMuxer.

[Beave]

Thanks Suiryc for your great tools. I just came across them.

I first tried your OGMuxer to split and mux a file using a vbscript. It works when using this system: --frames "0 10000 10000 20000 20000". Maybe if you couls add another option for just splitting without throwing anything away would be great, but not totally nessecary.

What I greatly miss is the possibility to name those Parts after splitting. Something like

OGMuxer -s setup.omx -o "Friends.ogm" --frames "..." --partnames "301" "302" 303" "304"...

I'm encoding episodes from series to fit on one CD. So I take for example 6 episodes in one piece, encode them and want to split them afterwards. I modify the Log-File between the 2 Passes to put the keyframes at the splitpoints, so the vobsubfiles of each episode will work.

I tried your VirtualDub Modification and it works great for cutting an OGM with only one audio. Adding chapters is possible, but muxing a video with audio is not possible yet.
Unfortunatly the avs options don't work here. If I want to open a file via AviSynth it gives an error "File doesn't seem to be a valid PNG file". A bug, or something wrong with my AviSynth installation?

Anyways, keep up the good work.

[Suiryc]

Originally posted by Beave
I tried your VirtualDub Modification and it works great for cutting an OGM with only one audio. Adding chapters is possible, but muxing a video with audio is not possible yet.
Unfortunatly the avs options don't work here. If I want to open a file via AviSynth it gives an error "File doesn't seem to be a valid PNG file". A bug, or something wrong with my AviSynth installation?

Anyways, keep up the good work.
Eheh it's a little bug that was introduced with the PNG support. I just fixed it (I put version 2 of today on the site).
This should work again with AVS files now :)


Good idea about letting the user choose titles for the parts. I will see what I can do for that :).
I think the best would be something like : --maintitle "..." for the main title, and --titles #n "title 1" ... "title n" (as presently the parameters of commandline without option are considered as input files, I need to know here the number of titles you choosed).
Then if there is only one part, use the main title, for each part use the title proposed by the user, and if the number of parts exceed the number of titles, use the main title + " - Part #n" (which can be disabled anyway using the --title option).

[Beave]

Yeah, that sounds fine to me.

[Suiryc]

I thought of something maybe more usefull for the titles. If I can, why not something like : --title "bla ... bla{{...%n...}}" to replace the actual --title option.
So if there are parts, use the {{...%n...}} block and replace %n by the part number, and just delete the block when there is no part.
This can replace the --title option because with that the user decide if something must be added to the title or not (and he/she also decide what will be added, i.e. maybe something different than " - Part %n").

What do you (users) think ?


@AmiRage
I tested to cut samples of 10 or less frames (with a clip containing two audio streams, subtitles and chapters), but this was OK :/
I will do some more tests with other clips ...
What is the framerate of your clip ?

[AmiRage]

Originally posted by Suiryc
What do you (users) think ?Sounds good and flexible! :D

Originally posted by Suiryc
What is the framerate of your clip ?



5 Streams : 2 Vorbis, 0 Audio, 1 Video, 2 Text, 0 Old, 0 Unknown, 0 Invalid

=== STREAM 0 (VIDEO 1) ===
Stream Header :
Type : video
SubType : XVID
Size : 56
Time Unit : 400000 (in reference time)
Samples per Unit : 1
Sample Rate : 25.000
Default Len : 1 (in media unit)
Buffer Size : 60234
Bits per Sample : 24
Width : 640
Height : 384
End Of Stream reached : yes
Number of Pages : 175030 (0 skipped)
Number of Packets : 101235 announced / 101235 found (0 skipped), 101233 containing data (not header nor comments)
Number of Samples : 101233 announced / 101233 found
Samples per Packet : 1.0
Packets per Page : 0.6
Bytes : 7709407 (headers) + 747842141 (bodies) = 755551548 (720.55MB)
Percentages : 1.020% for headers + 98.980% for data
Packet bytes : 747842141
Bytes per Page : 44 (header) + 4272 (body) = 4316
Bytes per Packet : 7387
Duration : 01:07:29.320
Estimated BitRate : 1477.5 kbps
Frames per Second : 25.000 fps

=== STREAM 1 (VORBIS 1) ===
Stream Header :
Type :
SubType :
Size : 56
Time Unit : 10000000 (in reference time)
Samples per Unit : 44100
Sample Rate : 44100.000
Default Len : 1 (in media unit)
Buffer Size : -1
Bits per Sample : 2
Number of Channels : 2
BlockAlign : 0
Average Bytes per Second : 12000 (96.0 kbps)
End Of Stream reached : yes
Number of Pages : 10196 (0 skipped)
Number of Packets : 260947 announced / 260947 found (0 skipped), 260944 containing data (not header nor comments)
Number of Samples : 178575552 announced / 178575616 found
Samples per Packet : 684.3
Packets per Page : 25.6
Bytes : 544753 (headers) + 42830664 (bodies) = 43375417 (41.37MB)
Percentages : 1.256% for headers + 98.744% for data
Packet bytes : 42830664
Bytes per Page : 53 (header) + 4200 (body) = 4254
Bytes per Packet : 164
Duration : 01:07:29.332
Estimated BitRate : 84.6 kbps

=== STREAM 2 (VORBIS 2) ===
Stream Header :
Type :
SubType :
Size : 56
Time Unit : 10000000 (in reference time)
Samples per Unit : 44100
Sample Rate : 44100.000
Default Len : 1 (in media unit)
Buffer Size : -1
Bits per Sample : 2
Number of Channels : 2
BlockAlign : 0
Average Bytes per Second : 12000 (96.0 kbps)
End Of Stream reached : yes
Number of Pages : 8879 (0 skipped)
Number of Packets : 245866 announced / 245866 found (0 skipped), 245863 containing data (not header nor comments)
Number of Samples : 178575168 announced / 178575232 found
Samples per Packet : 726.3
Packets per Page : 27.7
Bytes : 485613 (headers) + 37198686 (bodies) = 37684299 (35.94MB)
Percentages : 1.289% for headers + 98.711% for data
Packet bytes : 37198686
Bytes per Page : 54 (header) + 4189 (body) = 4244
Bytes per Packet : 151
Duration : 01:07:29.323
Estimated BitRate : 73.5 kbps

=== STREAM 3 (TEXT 1) ===
Stream Header :
Type : text
SubType :
Size : 56
Time Unit : 10000 (in reference time)
Samples per Unit : 1
Sample Rate : 1000.000
Default Len : 1 (in media unit)
Buffer Size : 16384
Bits per Sample : 0
End Of Stream reached : yes
Number of Pages : 203 (0 skipped)
Number of Packets : 203 announced / 203 found (0 skipped), 201 containing data (not header nor comments)
Number of Samples : 4049320 announced / 4049320 found
Samples per Packet : 20145.9
Packets per Page : 1.0
Bytes : 5684 (headers) + 5721 (bodies) = 11405 (0.01MB)
Percentages : 49.838% for headers + 50.162% for data
Packet bytes : 5721
Bytes per Page : 28 (header) + 28 (body) = 56
Bytes per Packet : 28
Duration : 01:07:29.320
Estimated BitRate : 0.0 kbps

=== STREAM 4 (TEXT 2) ===
Stream Header :
Type : text
SubType :
Size : 56
Time Unit : 10000 (in reference time)
Samples per Unit : 1
Sample Rate : 1000.000
Default Len : 1 (in media unit)
Buffer Size : 16384
Bits per Sample : 0
End Of Stream reached : yes
Number of Pages : 203 (0 skipped)
Number of Packets : 203 announced / 203 found (0 skipped), 201 containing data (not header nor comments)
Number of Samples : 4049320 announced / 4049320 found
Samples per Packet : 20145.9
Packets per Page : 1.0
Bytes : 5684 (headers) + 5608 (bodies) = 11292 (0.01MB)
Percentages : 50.337% for headers + 49.663% for data
Packet bytes : 5608
Bytes per Page : 28 (header) + 27 (body) = 55
Bytes per Packet : 27
Duration : 01:07:29.320
Estimated BitRate : 0.0 kbps


Total bytes : 8751141 (page headers) + 827882820 (page bodies) = 836633961 (797.88MB)
Percentages : 1.046% for headers + 98.954% for data

It can't be in some way related to the used filesystem or something?!

[Suiryc]

Originally posted by AmiRage
It can't be in some way related to the used filesystem or something?!
I don't think so (at least it cannot be a filesize problem ;)).
Why are you wondering?

PS : have you tried cutting other parts in the clip (to see if it is a general problem, or related to the part you wanted to cut) ?

[AmiRage]

Originally posted by Suiryc
Why are you wondering?

PS : have you tried cutting other parts in the clip (to see if it is a general problem, or related to the part you wanted to cut) ? I'm wondering because you're not experiencing my problem. :D

And yes, I tested several different short cuts ... always the same. It seems to get worser when the cut-part is closer to the beginning of my 800 megs file (if the rest is processed in memory only then this is explainable).

When using the same cut entry but a longer part it works.

I'll too make some further testing ...

[AmiRage]

A small update on my experiences concerning the small part big problem issue. :D

I just made some test runs with different cut part lengths (250, 1000 and 2000 frames) with the cut entry somewhere in the middle (to be exact at frame 50000) of the above mentioned OGM file.

Always after keeping the second part and echoing "Status in OGMCutter.cpp : Skipping Part 3 ..." the cpu load's rising to 100 percent ... but ... the longer the cutted part the smaller the period of this cpu peak.

So when cutting 2000 frames a peak load period too appears, but this one is relatively short ... and OGMCutter completes without severe problems, but the smaller the frame number to be cutted gets the (exponentially) longer this peak load period remains.

[Suiryc]

Originally posted by AmiRage
Always after keeping the second part and echoing "Status in OGMCutter.cpp : Skipping Part 3 ..." the cpu load's rising to 100 percent ... but ... the longer the cutted part the smaller the period of this cpu peak.
In all cases does the part you wanted to be cut is correctly generated ?

I made other tests on other clips (also cutting @ frame 50000 to see) but never get anything that weird :/

What is your OS? Does anybody else have the same problems?

[AmiRage]

Originally posted by Suiryc

In all cases does the part you wanted to be cut is correctly generated ?

What is your OS? Does anybody else have the same problems? Yes, the parts are correctly. But I didn't try "very" small parts as this would run for several hours.

My OS is Windows XP.

Just made two additional test runs:

(1) ogmcutter -f "50000 51500 75000 76500 90000 91500"
=> cpu peak load after the first kept part, rest runs without any problems/peaks

(2) ogmcutter -f "75000 76500 90000 91500"
=> cpu peak load again after the first kept part, rest runs without any problems/peaks

Strange?! :D

[Suiryc]

I have Windows XP too.

Did you tried "format c:" ? Allways solved a lot of problems for me under Windows ;)

Stupid question : you have the latest ogg.dll and vorbis.dll files ? (included with OggDS)

[AmiRage]

Originally posted by Suiryc
Stupid question : you have the latest ogg.dll and vorbis.dll files ? (included with OggDS) Yes, i have, and this installation of Windows XP including SP1 is clean and never saw another version of OggDS/SubTitDS than the latest available. :rolleyes:

[Beave]

I tried some small cuts and everthing works fine here. Sorry, AmiRage.

@Suiryc
How is the new OGMUxer Version going? I had the idea that i could also start the OGMuxer for each part seperatly to give it a unique name. But OGMuxer would start analyze the File each time it starts, right?

Are you planning on enhancing VirtualDubOGM? Maybe it will even be possible to mux all the streams in VDubOGM and cut them? That would be great. But your tools would probably become obsolete then (at least when it comes to user interaction).

[AmiRage]

Originally posted by Beave
I tried some small cuts and everthing works fine here. Sorry, AmiRage.
Thanks, I'd guess I'm giving up on OGM for the moment. I don't know why, but I'm currently only experiencing problems with OGM.

Maybe I'll install only Windows XP plus OggDS/SubTitDS on weekend for test purposes ... :mad:

[Suiryc]

@Beave
Yes each time you use OGMuxer it will analyze the file.
Yes I think of enhancing VirtualDubAVS&OGM, but presently I have other things to do (try to find what is AmiRage problem, there is also something weird with OokzDVD concerning the subtitles, maybe my mods will be included in VirtualDubMpg2 project, ...) ;)

@AmiRage
I will make a special version for you that will output everything it does.
Maybe this will give me some more hints on what's going on ...

[AmiRage]

Originally posted by Suiryc
@AmiRage
I will make a special version for you that will output everything it does.
Maybe this will give me some more hints on what's going on ... Thanks, but I'll first make some test runs with OggDS 0.9.9.4 as this version worked/works flawlessly so far ...

[Suiryc]

You will find the "debug" version here (http://cyrius.bunkus.org/OGMCutter_1.0a1_Debug.zip).
You use it as usual except you put " > C:\Log.txt" at the end of your command line.
This will send all outputs to the Log.txt file.
You will only see the progress of each step (so 2 times 0->100%).

At the end (or when you killed the app because it took all your memory ;)), you compress the Log.txt file (should be 80MB for your 800MB file; use, in order of preference, WinRAR, WinACE or WinZIP). The compressed file should be between 1.25-1.75MB), and you send me the file (suiryc AT yahoo DOT com).

Thanks

[AmiRage]

Thanks for the debug version.

It's running now for about 25 minutes at peak load while consuming about 240 megs of RAM. :D ... Progress: 2.13 %.

It's only a matter of days ... ;)

[Suiryc]

Your problem is really strange ...

At first sight everything seems to work as expected (the log file doesn't reveal anything weird :/), nevertheless your system doesn't tell the same ...

When creating the first file it is normal there is a memory peak because I allocate a 8MB buffer between my routines and writing into the file ... but 180MB is far beyond that ;)

In your various tests, can you tell me if the memory was freed during processing ? (i.e. you have the 180MB memory peak, but then a few seconds after - and before the end of the process - all went back to "normal")
Does the memory is linearly allocated ? (i.e. it is not a "real" pick where the memory used go from 20-30 to 180MB in no time)

I don't think I asked this or if you mentioned it, but does this happen only with this clip or with others too ?

Then does anybody having similar specs (Windows XP - SP1 + latest OggDS / SubtiDS) experience the same problems when cutting small parts ?


PS : and finally did you tried with a former version of OggDS (0.9.9.4) ?

[AmiRage]

Originally posted by Suiryc Your problem is really strange ...
Thanks!
In your various tests, can you tell me if the memory was freed during processing ? (i.e. you have the 180MB memory peak, but then a few seconds after - and before the end of the process - all went back to "normal")IIRC it was freed. But I'll do some further testing on this.
Does the memory is linearly allocated ? (i.e. it is not a "real" pick where the memory used go from 20-30 to 180MB in no time)The memory usage is growing linearly. Some further observation here too.
I don't think I asked this or if you mentioned it, but does this happen only with this clip or with others too ?Currently I only tested with this 2 x 800 MB clip I created using OGMuxer. But I'll test it with another clip when space and time allows.
PS : and finally did you tried with a former version of OggDS (0.9.9.4) ?Yes, exactly the same problem. Even when creating the clip with 0.9.9.4

[AmiRage]

I'm getting crazy about this ...

(1) The memory is always freed at the end.

(2) My Problem seems to be related to (my?) subtitles ...

I just muxed the same source material with different combinations and made exactly the same cut runs:

1. 1 XviD and 1 OGG -> no problem
2. 1 XviD and 2 OGGs -> no problem
3. 1 XviD, 2 OGGs, chapters -> no problem
4. 1 XviD, 2 OGGs, 1 subtitle (Danish), chapters -> CPU peak/increasing memory usage on/after first writing
5. 1 XviD, 2 OGGs, 1 subtitle (Finnish), chapters -> CPU peak/increasing memory usage on/after first writing
6. 1 XviD, 2 OGGs, 2 subtitles, chapters -> CPU peak/increasing memory usage on/after first writing
7. 1 XviD, 1 OGG, 1 subtitle, chapters -> CPU peak/increasing memory usage on/after first writing
8. 1 XviD, 1 subtitle, chapters -> CPU peak/increasing memory usage on/after first writing
9. 1 XviD, 1 subtitle -> CPU peak/increasing memory usage on/after first writing

The subtitle(s) only seem(s) to cause trouble on cutting, but not on muxing. And "cutting" while muxing is also no problem.

[Suiryc]

Ah ah, some more hints :)
Could you send me those damn subtitles :) (maybe I could obtain the same problems muxing other clips with those subtitles) (I like having memory peaks ;) )

It's normal the memory is freed at the end (Windows does it if the program forget to do so).

[AmiRage]

Originally posted by Suiryc
Could you send me those damn subtitles :)Are you an adult? :D ... especially when you're able to read danish or finnish. :)

I'll make some further test runs with each of the languages, post the results and send you the subtitles.

[Suiryc]

Originally posted by AmiRage
Are you an adult? :D ... especially when you're able to read danish or finnish. :)
Well I am not able to read danish or finnish (I am French, can write/speak english, and know a few words in spanish), but this will be enough to mux the subtitles with another clip :D
And yes I am an adult :p


PS : why are you asking that? Did some words in my posts have other meanings that the one I thought? (my english is not perfect :( )

[AmiRage]

Originally posted by Suiryc
PS : why are you asking that? Did some words in my posts have other meanings that the one I thought? (my english is not perfect :( ) No! :D ... because of the content of the subtitles. :)

P.S.: Subs already on their way!

[Emp3r0r]

@siuric: I use your ogmuxer all the time and I have a few more feature requests as it seems it would make make life easier if ogmuxer could do the following things:

Take .omx file that will handle the following additions
<size>794</size><!--target size-->
<firstframe>680</firstframe><!--first important frame-->
<lastframe>189827</lastframe><!--last important frame-->
<titlemode>false</titlemode><!--no parts in title-->

and returns a file that is as close to 794 megs as possible and keeping as many frames between 680 and 189827 (frames at beginning should keep precidence over frames at end) with all chapters modified (only if frames from beginning must be cut) and no Part 1 in the movie title. It should also report wether it was successful at creating the ogg stream including all frames between firstframe and lastframe at the target size and report (if unsuccessful) the size required to fullfill the inclusion of all important frames.

I can explain more if you don't see my reasoning, otherwise just tell me if any of this is unreasonable. Thanks

[Emp3r0r]

Ok, I thought of one more thing which would be affected by my requests. I usually overwrite the first frame of my movies with the title frame (so it shows in thumbnails in explorer or when I push stop in zoomplayer). Anyway, how hard is the process of appending a keyframe (1 frame ogg stream) in front of an existing ogg stream?

[Suiryc]

@AmiRage
LOL :), you know what is the problem? People don't talk enough (no kidding) :D
This won't be easy to correct my tools so that they work correctly in this case, but I will do my best :)


@Emp3r0r
Looks like you sometimes get oversized clips ;)
For the title don't worry I am modifying the feature so that you can choose how it will looks like (i.e. a fixed title, a special title for a certain number of parts, or a title that adapts according to the part number - and where you choose that you put " - Part %n" or anything you want in it).

For the first_frame->last_frame you can also use
--frames "first_frame last_frame" --split max_size --simulate
that will tell you how OGMuxer would have cut your clip (so you can see in how many parts the first_frame->last_frame would have been cut, and what is the size of each part).

For the adding of a frame at the beginning, I think it is possible to do.
But I will add this feature when I have enough time or if other people think it is usefull (I think you understand I cannot add a feature at each user request if this feature only concerns this user ... because if not I would have to code till the end of my life ;) ).

[AmiRage]

Originally posted by Suiryc
LOL :), you know what is the problem? People don't talk enough (no kidding) :D
This won't be easy to correct my tools so that they work correctly in this case, but I will do my best :)Come on, you're kidding!? :D Or is this really true? This is the cause for my problems? :D :D :D I can't believe it.

[Suiryc]

Well at least it is my best explanation for what is happening.

The fact is that sometimes there is too much time between two subtitles.
This, combined with the fact I do not handle this situation correctly, make my routines expect data from the subtitle stream between those two subtitles, and data coming from other streams are stored in memory in the meantime.

One example : the first subtitle starts @ 00:11:??.???. If I wanted to cut the clip between 00:00:10.000 and 00:00:20.000, then I would have data representing about 10 minutes of the clip pending.
Your clip lasts about 1 hour, for 800MB, so 10 minutes = 800 / 6 = 130MB (just for the data, I need some more memory for the structures holding those data) pending in memory.

[AmiRage]

Thanks for explaining. Hope you can find a way for this special case of subtitles. :D

Thanks in advance.

[Suiryc]

Well OGMCutter v1.0a2 should solve your problem :)

I also put the modification concerning titles modification in it.

[Beave]

Well OGMCutter v1.0a2 should solve your problem
I also put the modification concerning titles modification in it.

Why didn't you put it into OGMuxer? I thought OGMuxer can do the same thing, so OGMCutter is redundant.

[AmiRage]

Originally posted by Suiryc
Well OGMCutter v1.0a2 should solve your problem :)
Thanks, Suiryc! The first test with a small cut at the very beginning of the OGM ...

ogmcutter -f "1700 1950"

... worked very well with a IMHO lower overall cpu and memory (about 10 MB) load and no peak load during the cutting process.

... but ... :D ... the second test run using ...

ogmcutter -f "10000 11500 50000 51500 90000 91500"

... made the peak load reappear on the second cut. :confused:

Update: The problem hasn't gone away, it now doesn't happen on the first cut (so far) but on following parts.

[Suiryc]

Originally posted by Beave
Why didn't you put it into OGMuxer? I thought OGMuxer can do the same thing, so OGMCutter is redundant.
I am going to put it OGMuxer too.
But I didn't code the two tools the same way, so it's a bit different to do for OGMuxer ...


@AmiRage
Well I will do some other tests then

[Suiryc]

Oops I think I forgot something in the code ;)

So for AmiRage, OGMCutter v1.0a3 should work now (I really hope so :))

And for Beave there is OGMuxer v1.0a8 that also have the title modification feature. (this version has not been updated regarding AmiRage problem because it seems there are less problems with OGMuxer so I need to investigate a bit to know what I need to modify)

[AmiRage]

Originally posted by Suiryc
Oops I think I forgot something in the code ;)

So for AmiRage, OGMCutter v1.0a3 should work now (I really hope so :))
No it works fast and fluently ... although there are some very short higher CPU load peaks, but it works really great. Thanks so much! :)

Maybe I can find some other specials ... :D