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.
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.
I don’t doubt it, but don’t you find yourself rather burdened with the rest of
librempegthat has nothing to do with your DSP stuff but which you still have to maintain nevertheless?The ages of real serious work like heavy refactoring, improving, RE, and inovations are long gone in jbmpeg. There is no real burden whatsoever.
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.
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.
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
jbmpegnot 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
avconvfor some things either. Maybe I’m making life harder for myself but it does not affect anybody else.Hello, I’m here from a web search, interested in a VX decoder. I can’t seem to be able to clone your git repo, do you have some binaries available perhaps?
Thanks.
Probably the hoster forbade cloning git because of too much bandwidth. You can still browse the sources and I can provide Git bundles for direct downloading.
BTW, what do you want to do with it?
I want to convert a video file I obtained from a DS game (Duel Love: Koisuru Otome wa Shouri no Megami) into an usable format.
Here’s the video file if you’re interested: https://files.catbox.moe/tevspm.vx
I’ll try to make sure my tools are adequate (and available) for such task. Meanwhile your file is invalid—VX files should start with “VXDS” while yours starts with something completely random and such signature is nowhere to be found. At least I’ve managed to spot several Nitro palette files closer to its end (with padding between them), probably your extraction has gone wrong.
Okay, here’s a working solution that I tried on some VX samples I have:
nihavandnihav-encoderfrom https://nihav.org (the links are right on the main page);Cargo.tomlinnihav-encoderto point tonihavcrates;cargo build --release(debug version may be too slow for your patience);nihav-encoderto convert VX files into AVI with video stream and WAV with audio stream (I have not bothered with audio synchronisation so if you re-encode it into AVI with sound the players may go crazy);Audio track can be extracted with
nihav-encoder --ostream0 encoder=pcm -i infile.vx -o audio.wavVideo track can be re-encoded with
nihav-encoder -an --ostream0 encoder=zmbv,compr_level=none,range=0 -i infile.vx -o video.aviZMBV codec is not standard but a lot of software can decode it just fine (and it’s lossless). You can use
--ostream0 encoder=zmbvoption instead for a slower but more effective compression.The tools are made for my needs so they lack a lot of features but hopefully this will work just fine.
Good luck!