jPSXdec forever

According to Ohloh, jPSXdec is worth at least $150,000, but that is for code from a year ago. It now has now swelled to over 28,000 lines of code in over 170 files, and will probably be past 30k LOC by next version's release.

I really wish I could work on jPSXdec non-stop until it's ready for prime time again. School, work, the economy, a seriously expensive family emergency, and some critical life changes have all conspired to make that impossible. In fact, I don't have much hope in seeing the next release available anytime this year.

Things completed so far:
* The complicated part of media playback (managing 6 simultaneous threads isn't easy)
* Much needed cleanup of the Tim decoder, XA ADPCM decoder, and serialization code
* Reorganized the arrangement of media streams verses more static types of media
* Fixed both bugs on the issue list.
* Fixed the Tim false-positive matching that happens fairly often
* Fixed FF7 frame-rate miscalculation
* Break things up by game (i.e. setup plugin system)
* ISO9660 file detection
* Improved detection of audio (including CD-i) and video media items
* More robust disc image detection

Still to do:
* Re-implement the saving process for the various media types
* Redo frame rate detection

Beyond the next release:
* Automatic error reporting
* Redo the GUI
* Append AVI writer to make it stricter so it can produce cleaner AVI files
* AVI PNG codec
* Yuv4mpeg2 writing and/or AVI YUV codec
* Real-time media playback/preview
* Searching for static demux and MDEC data
* Finding and uncompressing lhz data, often used in PSX games
* Raw direct CD reading from the disc drive (based on java-avm)
* CD-i video formats
* More game handling
* STR and XA re-encoders
* CD track audio handling

When hell freezes over:
A custom hex browser for jPSXdec. Other free and/or open source hex browsers are generally decent, but none do everything I really need. Some desired features:
* Viewing of very large files without loading the whole thing into memory (hundreds of MB)
* Quick viewing and editing values as big/little endian of varying bit sizes/signs/types
More specifically for PSX hacking
* Identifying and browsing by sector (much like CDmage and IsoBuster do)
* Highlighting of the sector headers and footers
* Viewing of continuous demuxed sector payloads
* Identification of known sector types, and the various fields in each
* An overview map of the entire CD, with quick identifying symbols/colors for every sector and its type
The closest thing I've seen to this is VirtualDub's hex viewer.

And the ultimate pièce de résistance:
* Real-time processing of the data as you mouse-over it, and showing how it results in the final output
* Allows you to take each bit of data in the disc and follow it through the entire decoding process, each step of the way
* Allow you to change anything in real-time, and see how it would turn out
I've repeatedly imagined a program like this for even just mpeg1 or 2 streams. Those streams are really complicated, and you never get to see the direct connection between the data and the output. It would be so neat to hover over a block or a macro block and be able to see exactly where it was going to end up on screen, how it will look, and everything around it. The whole motion detection as well. It would be an incredible tool to teach people how those streams work. In the almost impossible case you've seen the official Bluetooth development tools, that's exactly what I had in mind.

All these neat ideas could eventually turn jPSXdec into the ultimate PSX hacking utility.

The time frame for everything? A long...long time. Years probably. Which really makes me wonder: what will become of this project in, say, another decade? Should I start soliciting help?

In the next to impossible case someone would like to join in developing jPSXdec, his skills might hopefully include:
* Very usable knowledge of Java (no need for an expert because I don't think I am)
* Love and value for clear and well documented source code
* Some experience with reverse-engineering just about anything (media formats preferred)
Added bonus:
* General understanding of mpeg/jpeg-type image formats
* Awareness of cross-platform development issues, and/or experience with developing simple programs for multiple platforms (i.e. Windows, Linux, Mac)

Comparing Media Quality of Playstation 1 games

I suppose very few people have ever looked as closely at Playstation 1 media as I have. Of those that have, I assume most worked for Sony, or developed games using the official SDK. Of the few that never got that approved proprietary insight, almost all are Japanese. Finally, of those even fewer remaining whose primary language is English, almost none care anymore at this late date. So I thought I'd take a moment and share some of what I've observed.

To my knowledge, only one game has actually used custom variable-length (i.e. huffman) codes in its video streams: Serial Experiments Lain. The infamous logo.iki sample may also use custom huffman codes (it sure doesn't use the standard ones), but until I find what game it's from I can't know for sure.

Now I assume S.E. Lain's use of custom variable-length codes means its video quality is higher than if the standard set was used, else why would they use it? Its custom decoding software also took full advantage of every last bit of space available to each frame. I've never seen games using the standard SDK decoder that pushed their buffer to the limit. And if that wasn't enough, it sacrificed as much audio quality as it could to increase space for video bandwidth.

I find this all terribly ironic because the quality of the game's artwork is downright awful.

So while S.E. Lain's video quality is pointlessly top-notch, its sound quality is not only bad, it is probably one of the worst. The audio was encoded very poorly, with many of the loud moments pointlessly sawed to half the dynamic range, creating excruciating distortions.

It's a crying shame, because even though everything about the game was different from the anime series, at least the audio contained more work by the original Lain voice actress, Kaori Shimizu.

Lain's video decoder also took a small speed hit because the data is stored as big-endian. This means that the little-endian Playstation platform has to take a moment to reverse every 32bit value read from memory. Who knows, maybe reversing it would have sped up the animation of Lain while drudgingly browsing all those media items.

The game that I've seen with the next best video quality trick is Alice In Cyber Land. It may be the only game that uses variable frame rates. During times with less video action, the frame rate could be dropped, giving the images more bandwidth for detail. When the action picked up again, the frame rate and quality could return to normal so the more rapid frame changes could be shown. I suspect any game's video could be modified to use this feature. In fact, it's really too bad that the official Sony SDK encoder didn't use this trick. So many game videos might have looked even nicer.

Meanwhile, on the good end of the audio quality spectrum, Square's (now SquareEnix) custom audio format provided the best audio experience of any games I've seen. Its unique format, used in several of their RPGs, produced almost twice the quality of the best standard SDK audio format. An entire sector was devoted to each left/right audio channel, and at intervals that resulted in nearly CD quality output.

Through the Digital Looking Glass

While exhaustively reverse-engineering the Serial Experiments Lain game, always in the back of my mind was an article I read years ago. It describes some curious connections between Lain, and another game called Alice In Cyber Land.
http://www.cjas.org/~leng/alice.htm

So naturally, once the Lain game hacking was thoroughly complete, my attention quickly turned to finding the secrets Alice held.

The work to discover the unique ways the game stored its videos really paid off. The Alice videos were all well animated, and suggested a game that could be a lot of fun. But for now I must be content with its raw Japanese clips, all of which can now be viewed on Youtube.

The Alice In Cyber Land franchise didn't stop with the game. It also included a soundtrack, and short OVA. It seems at least episode 1 was fansubbed by a group called "Boot To Da Head" back in 1997. The first episode is now watchable in very low quality, raw Japanese.

While the connections between Lain and Alice are intriguing, you might be interested to know that they don't end there. Tucked away in a corner of the internet is a little account by one of the game's creators that extends the connections to one more series: Digimon Tamers.
http://www.konaka.com/alice6/tamers/characters/juri-e.html

CD-i

I was pleasantly surprised when I found someone concocted a clever way of using jPSXdec to decode CD-i audio.

As explained in Jonathan Atkins's CDXA documentation, the Sony Playstation 1 and the Phillips CD-i both used the same audio format on their CDs. It never occurred to me that the CD-i likely has a retro community still following it, much like the Playstation 1 does.

This video describes a working solution to extracting CD-i audio with jPSXdec that will work with any game. However, after the extraction, you have to manually break up the audio clips and possibly adjust the speed of some.

Alternatively, you could do the job that jPSXdec can't yet do so the extracted audio clips don't need any extra editing.

If you let jPSXdec do its best to index the CD (or raw music file), it will find all the audio sectors, but fails to concatenate most of the contiguous streams. You're left with several thousand audio clips with a duration of 1 sector. It wouldn't be too difficult to write a script that checks the audio properties (channel, frequency, etc) and finds what sectors should be combined into a single audio clip. It even sounds like someone has already managed to make some headway with this.

Adding better CD-i audio handling to jPSXdec is quite easy, and will be included in the next release (whenever I can get this redesign finished). As for CD-i video, I can't say I have much motivation (or time) to figure it out. But if anyone wants to get their hands dirty and write some decoding code of their own, I'd be happy to support them however I can.

Java real-time video playback

Much of the easy changes have already been made to jPSXdec. The biggest and hardest change left is implementing real-time playback. To do this in pure Java is tricky. I've spent a month looking at every kind of Java video player out there.

I want to keep jPSXdec as cross-platform and simple-to-use as possible (Just Work™). So while the JMF has Java-only implementations for playback, it needs a separate installation, has far more functionality that I need, and being closed source doesn't help. It's curious that even though the JMF has plenty of documented bugs, and hasn't been updated in years, it's still the de facto Java media standard. Meanwhile, the FMJ library is open source, but it's even bigger than JMF, and uses JNI to wield each platform's native playing capabilities. I've examined various other small libraries, but nothing met my needs: a simple synchronized audio and video player. So I'm stuck trying to figure out how to do it myself.

Initially I thought to duplicate the general design of JMF/FMJ since it seems to work for them. It would also help someone with greater familiarity with those libs to take the next step and properly integrate PSX decoding into them. However, after several days of tearing apart those massive libraries, and seeing I'd only scratched the surface, I dropped that idea.

Finally went back and took a closer look at SurePlayer. It plays mpeg1 movies great with very little processor use. It's fully cross-platform, and is a much more digestible library, so I'll be using that as a guide for implementation. With this clear direction, I can push forward with more jPSXdec development. Maybe in several years when Java 7 is ubiquitous, jPSXdec can be changed to utilize the new JMC.

Also during my searchings I serendipitously ran across a Java library to handle cross-platform raw CD reading! It's not quite as clean as I would like, but it's a pretty good foundation to build upon.

In other news, we've had a couple translators pop out of the woodwork recently. Will they be the salvation this project so desperately needs?

A man can dream.

How to encode quality PlayStation 1 video

Recently I've run across a couple of groups trying to replace the video of a Playstation 1 game. As we have to do the same thing with S.E. Lain, I thought I would share some insight as to how it might be done with the highest quality output.

Since there are many things that go into encoding mpeg video, that step is best left to programs that know how to juggle those options, such as ffmpeg. It also allows you to tweak those options, and use its advanced features to get the best results.

So here is how you do it, broken down into 6 ridiculously complicated steps.

1. Convert your video into 4:2:0 yuv4mpeg2, but using the PSX specific rgb->yuv conversion.
2. Feed the yuv4mpeg2 video into ffmpeg at an allowed fps and create a mpeg1 movie with only I-frames (-intra). This should be done at a variety of different quality levels (-qscale from 1 to n).
3. Parse the I-frames out of the movie and parse their macro-blocks
4. Convert the mpeg1 VLCs to PSX VLCs
5. Do this for every mpeg1 quality and pick the one that fits best within the amount of space available to the frame
6. Multiplex the frames and construct all the sectors

If the new video is mostly just the old video with some changes (e.g. subtitles) then quality can improved tremendously with this variation.

5. Use some method to determine which macro blocks to replace (manually picking them, or performing a diff on lossless video data, or a fuzzy diff on lossy video data)
6. Only replace those macro blocks with new ones of the same qscale
7. If the replaced data makes the frame too big, then either replace the entire frame with an ffmpeg created frame that will fit (qscale will probably be bigger), or remove some quality in the frame to make it smaller
8. Multiplex the frames and construct all the sectors

Alternatively have ffmpeg write an AVI using MJPG codec and parse the JPEG frames and convert the JPEG VLCs to PSX VLCs (I'm not sure how to get ffmpeg to produce quality variations with the MJPG codec).

zOMG psx.lain.pl is down!

And it has been for quite awhile. I thought it was just temporary, but finally learned yesterday that the good fellow that was nice enough to host the page has chosen to close the account. We are grateful for the time we could use the server.

Don't worry, we still have all data and work done so far. Unfortunately we're currently without a host, and the project is still stuck at around 14% completion.

I personally would like to thank everyone that has contributed thus far...

Hikari - Translated dialogs from video sequences to Polish.
phm - Extracted the media with jpsxdec and setup the wiki. Retranslated video sequences dialogs from Polish to English. Advertised for translators, and coordinated with their changes.
MercuryTW - Provided some translations from a translator of his own (Keigo). Edited/corrected translated files.
stalker-kun - Provided hosting for the wiki.
otakufish - Provided some translations.
toruvinn - Provided nice domain.
farhan - Ruthlessly proofread random translations, utilising his qualifications in the field of Applied Pedantry with Grammar Nazism.
fishy - Proofread translations, created the public project page.
arc - Provided some translations.
Jossos - Provided some translations.
utakata - corrected a Japanese transcription.
Najica - Provided some translations.
Quibbage - Created subtitle files for videos.

...and everyone else (sorry if I've missed your name here)--thank you all very much.

jPSXdec development has been pretty quiet as well. I should submit the bug that fails to decode some of the Lain videos, or just commit the fix. The next things to do with jPSXdec require some major changes, and things have been busy (my toon won't hit level 60 by itself ;). I'm still here and interested in the project and related topics. I don't plan on that changing anytime soon.