How to programmatically split a movie file into separate parts? - scripting

i'm exploring ways to split a movie file into N separate/complete/shorter files programmatically. Do any of you have suggestions for what software or scripting language to do this?
I do not necessarily want to break them down and reassemble them again, rather i just want to split, for example, myMovie.avi into myMovie1.avi, myMovie2.avi, ..., myMovieX.avi
I'm currently exploring Flash, Ruby, Python, Java and more for the best option. Please let me know!

It's a pretty straightforwad process that you can achieve with any scripting language and something like ffmpeg.
I think this could be of help: http://icephoenix.us/notes-for-myself/auto-splitting-video-file-in-equal-chunks-with-ffmpeg-and-python/

Related

How do i translate my idml file using okapi rainbow application?

So as the question suggest I have an idml file along with a xliff file for translation. I'm using okapi rainbow application for translation purpose. But I'm having a hard time understanding how do I translate my idml file?
P.S - If anybody feels this question does not belong to programming section please move it to an appropriate section rather than downvoting. Thank you.
Also, i could not create new tags such as okapi or okapi-rainbow as I do not have the appropriate reputation.
Your question is not related to programming, but it may be relevant to everybody who develops software that is intended for users that speak different languages, so I will try to answer it here.
You mention that you have an IDML and an XLIFF file and you want to translate the IDML file. This approach does not really make sense: a typical translation workflow would be
extract translatables from native format (IDML in your case) into XLIFF
send XLIFF to a translator
get translated XLIFF back
import translated XLIFF into native format
do post-translation processing (adapt fonts, resize text boxes, update tables of content, to name just a few)
Okapi Rainbow is a tool that you can use for steps 1 and 4 in the process above. It will not perform automatic translation for you.
Actually the first thing you should do is ask your translator if he can process IDML. Some translation environments have built-in support for IDML, in which case you don't have to bother with providing XLIFF.
It might be a bit off-topic here.
I'm not sure how to get from IDML to XLIFF, but maybe there is a filter.
But if you got the XLIFF, you can just use OmegaT to translate it.
Or pretty much any other professional Translation Tool like e.g. SDL Trados.

Is there any recommended way to automate module port connection?

I'm trying to understand or research about the best practices of ASIC design in verilog. I'm working on a medium size block with ~20 sub modules (each ~1000 lines of code). It's a painstaking job to manually instantiate all the sub-module and do port connection to create top level RTL.
I want to write a script to automate this. As long as we can define the input/outputs of all the sub-modules and how each sub-modules are connected with each other, it shouldn't be super hard to auto-generate the top level. I don't have enough expertise in design automation though. I was wondering if anyone can give me some pointers about how to get started.
Is there any open source tool to achieve what I'm trying to do? I didn't find any so far.
Is there any standardize way to generate synthesizable code of this sort?
I'll highly appreciate any sort of input or advice.
Depending on what text editor you're using, you might be able to use some pre-existing tools. There is an add-on for Emacs that supports auto-instantiating and connecting signals, assuming that you follow certain naming conventions:
http://www.veripool.org/wiki/verilog-mode/Verilog-mode_veritedium
For the vim users out there, there are a couple of plugins that allow using the Emacs script, such as this one:
http://www.vim.org/scripts/script.php?script_id=1875

Automation scripts: autoitscript vs ptfbpro

I try to use this 2 projects for primitive gui testing automation:
http://www.ptfbpro.com/
http://www.autoitscript.com/
And I can't make my choice.
Can somebody explain me: why(in 2 or 3 lines) he use one of them(or other please specify)?
I use AutoIt...
because it's free, well documented (not only) from inside of the Scite Editor and you can easily compile your script into a small executable or even create a complete GUI and there is a very good community in the forums and around here. And its Basic-Like Syntax is really easy to understand, there are functions and even a foreach-syntax, dynamic arrays and lots of additional functions from other users... There's good integration with other programming languages and from the use of so many WinAPI functions you lack of very little possibilities. It can automate IE usage without even displaying a browser window and send network packages, you can send Keystrokes like a user sitting in front of your screen and there's the AU3Record Tool which allows you to just record a Macro and replay it or save it as a script and then you can easily optimize it and edit it for your needs. Or use the AutoIt Window Info tool to see all the possible handlings for your application, you can interact with any kind of program output/display according to different algorithms you may invent.
Enough facts? ;-)
Go with Autoit3. It 's a lot more reliable, and you have a complete script language. Ptfbpro is only a tool (not free), nothing more. AUtoit3 has a lot of contributors that can help you in your process, Ptfbpro is dead.
If you want a script taht really do what you want, just go for AutoIt. Ptfbpro can't be used as a professional tool.
Autoit3 as well. You really can't beat it for being free and so easy to use.

making osx modal

I've used applescript a lot, and I love it. But for some workflows it would be really neat to be able to go into a "mode" where single keystrokes would allow me to launch scripts, choose options in dialogs, interact with apps etc. It's my impression that this is impossible with applescript alone but doable with objective-c. What are my options? What do I google to start reading up on this?
PS. If there are several options I'd prefer the ones that work best with applescript (or python).
I think the best way is learning AppleScriptObjC, You write an cocoa application with AppleScript syntax. Like Apple says, with AppleScriptObjC you can write first class applications in AppleScript. If you have no experience with cocoa it can be very time consuming job to use the right objects and it's methods. So before you think, like many others, that there is a huge lack of documentation, your answers can be found in the Cocoa-Objective-C documentations and examples. A good book for people who are familiar with AppleScript already is Shane Stanley's AppleScriptObjC explored, that can be found here http://www.macosxautomation.com/applescript/apps/index.html.
Because you know python as well you could use PyObjC as well but I don't have experience with it.

API for parse/update UNIX configuration files

Unix configuration files come in all shapes and forms. I know that Webmin has a Perl API that makes it easy to parse and modify most common configuration programmatically, while preserving changes that might have been made by hand.
Are there any other libraries that has similar functionality, perhaps for other languages (Python, Ruby, C, C++, etc)?
At least for Python there are numerous libraries that intends to simplify parsing. One of the simplest might be picoparse (http://github.com/brehaut/picoparse) which is constructed to provide straight forward parsing without the need of regexps.
Another one worth a look might be funcparselib (http://code.google.com/p/funcparserlib/) also for python.
If you intend to use C the most common tools for building parsers are Yacc and Flex. These tools are rather complex and has a rather high threshold before being usable.
Ajenti, an alternative for Webmin written in Python uses reconfigure.
It is not as mature and complete as Webmin and it's API, but reconfigure looks like as good an answer to this question as I am able to find.