Re-revisiting Actimagine VX

As Paul said, I probably should do something more useful (and he should do something better than still messing with jbmpeg fork) but we’re all better at giving good advises than at following them.

Recently I was contacted by a guy who asked for my help on dealing with VX format as he needed video part extracted from it and there were no tools available. And he also provided some samples that helped clarify things I got previously wrong, for example the seek table and framerate field as well as stereo audio support.

Also since I bothered to extract video part (the only way to determine its length is to parse it, so now I have a stripped-down version of video decoder doing that) I decided to finally do something about the audio part. So after fixing some things (e.g. missing filter reconstruction or stereo support) now my decoder can decode VX files with recognizable audio (not perfect but who can do better is encouraged to do so). The sad thing is that I could not use my old setup (a console emulator with GDB stub) for debugging so I’m not likely to ever improve it.

At least it was a fun diversion and helped to improve the format knowledge a bit.

P.S. Meanwhile I’m still working on adding new formats for na_game_tool, hopefully I’ll have something to write about another game format soon.

6 Responses to “Re-revisiting Actimagine VX”

  1. Paul says:

    I’m doing very important and serious research & development in librempeg with DSP, instead of reverse engineering obsolete niche limited technology of previous and current century.

  2. Kostya says:

    I don’t doubt it, but don’t you find yourself rather burdened with the rest of librempeg that has nothing to do with your DSP stuff but which you still have to maintain nevertheless?

  3. Paul says:

    The ages of real serious work like heavy refactoring, improving, RE, and inovations are long gone in jbmpeg. There is no real burden whatsoever.

  4. Kostya says:

    I hope you’ll stay happy (in general as well as while developing what you like) and Anton won’t prove you wrong. As for me, I’d still not touch it.

  5. Paul says:

    Why do you dislike jbmpeg so much, from where such irrational judgement comes from? Talking about code here only, not about mortal limited coders coding it.

  6. Kostya says:

    You have wrong assumptions. While I find its codebase far from being good (IIRC even you commented on the nice issue of multi-threaded FFV1), there are much worse cases of code quality (most things from Xiph IMO fall into that category). But the social part is much worse (e.g. I don’t have problems with Xiph folks or Xiph project and can use their code even if I don’t like it, but you maintain your own fork of jbmpeg not because your code was below the acceptable standards). And I’m not talking about coders but rather other roles in the project.

    So I avoid it partly out of disgust and partly because I think there should be non-nominal alternatives. And I have no reserves against using old trusty avconv for some things either. Maybe I’m making life harder for myself but it does not affect anybody else.

Leave a Reply