Messages

1

Completely Unrelated / Re: Religion

« on: 2011-05-05 14:07:01 »

We could also say that there are plenty of creatures that don't like Justin Bieber, and that they're less intelligent than we are. So without Bieber fandom, we could be far less intelligent than we are today.

You are trying to imagine a world with humans having a fundamental difference in traits. Why try guessing based on various examples in human history (which are already tainted by their religious traits) when we can simply examine similar creatures that we *know* exist? And trying to compare liking Justin Bieber to a fundamental difference in evolutionary paths is laughable.

Not every evolved trait is useful, or still useful. Some of them are just leftovers that were useful at one time (just goes to show that our design is not "intelligent").

What makes you think superstitious belief is no longer a good survival trait? When do you think it became obsolete? Just saying it might be obsolete is a pretty weak argument against the reality of millions of years of humanoids dying because they failed to have the trait.

Come on Kudistos, you can do better than that.

2

Completely Unrelated / Re: Religion

« on: 2011-05-05 02:20:12 »

1) Can we assume religion primarily exists because people are born with the strong inclination to believe in the supernatural and superstitions? So if religion didn't exist, then that would mean humans weren't hard-wired to have such tendencies. How would we be in that condition? There are plenty of examples of
creatures on the planet that don't have such tendencies, and all those creatures are far less intelligent. So without religion, we could be far less intelligent than we are today.

2) Natural selection made us this way, therefore believing in the supernatural is very likely a good survival trait. So evolution clearly shows religious belief does indeed save more lives (or at least the lives that matter for the propagation of our species).

3

Completely Unrelated / Re: Christian fundamentalists in Britain

« on: 2011-05-01 13:37:55 »

Wow, this thread got crazy again.

I've found a flaw in your argument.

It's true that people have harmed others as a result of their religious belief. Maybe I should have included that acknowledgement in my first post. The question is, how is this different from many other tendencies? If there is no difference, then is religion really the problem? There's likely a flaw in this parallel, but haven't been able to find it yet.

Observing the observable when talking about a higher power is like trying to learn about the Sun by studying the Moon.  You can learn about the sun this way, but it is not the same as studying the sun itself.

But I thought higher powers were by definition not directly observable.

Religious belief operated independently of genetics (although people with certain genetic profiles are more or less likely to be believers or nonbelievers just as some are more likely to be gamblers).  The very nature of religion and spirituality, is something I believe is influenced by genetics and environment, but not dependent on genes or upbringing.  I’d be interested in knowing specifically what studied you are referring to (are these articles peer-reviewed? Are there any potentially confounding variables?).

I was under the impression that it's rather common knowledge that people are strongly inclined to supernatural/superstitious/religious ideas, especially given the wide acceptance of such beliefs throughout history and cultures. I assumed there had been plenty of scientific study on the topic, such as this article (including the scientist's helpful follow-up). Even Dawkins thinks it's a reasonable idea: "I am thoroughly happy with believing that children are predisposed to believe in invisible gods". But if that assumption is wrong, then it would be good to know.

Many natural tendencies for behavior DO hurt people.  If everyone followed their natural tendencies, I imagine the world would be a very dangerous and dreadful place.

Indeed, hence why people add the disclaimer "so long as it doesn't hurt others."

Thanks for your methodical answer. That's the kind of insight I was hoping for.


Now a new question for anyone with thoughtful replies. I've seen people espouse the idea of "moral axioms", and that moral systems can be built off those axioms and remain internally consistent. Since it's pretty hard to objectively define moral absolutes, having an internally consistent system may be the best you could get. Now organized religions receive a lot of criticism from people seeing internal inconsistencies in those beliefs. My question is, could those criticisms be seen as a "shell game"? I mean, it's really easy to criticize religions because their moral systems are actually published and known. On the other hand, it doesn't seem like those criticizing stand behind any well documented moral system that is open to good analysis. Is there perhaps some published, non-religious moral system out there that I am unaware of? Or does it even matter?

4

Completely Unrelated / Re: Christian fundamentalists in Britain

« on: 2011-04-27 05:28:38 »

Watching that this thread at least started out quite calm and respectful, I was interested in posing a bit of rhetoric to improve my understanding. I'm sure these ideas are not new by any means, so I'm curious what some of the standard counter-points are.

1) From my limited understand, the scientific approach relies on repeatable, observable experiments. There are many things we can't observe directly, so the best we can do is observe the things around them (e.g. fundamental elements of matter, or black holes). Where is the flaw in trying to draw a parallel between this and a "higher power"? 

2) Now to side-step the actual question of if religion is real. It has been accepted by many people that homosexuality is not a choice--it's just the way some people are. It's natural and, so long as it's not hurting anyone, there's nothing wrong with it. Of course this sort of "live and let live" idea can extend to most any inclination people have. What could be said, then, to someone who tried to draw a parallel to that and religious belief? It has been reported by psychological studies that we are hard-wired to have religious belief (e.g. applying meaning to random events). So, if following the natural tendency to believe in religion doesn't hurt anyone, is it any different from following a tendency to be (fill in the blank)?

Like I said, I'm sure these points have been raised countless times by others before me. But I hope some thoughtful feedback can help me grow in understanding.

5

Completely Unrelated / Re: Take heed...

« on: 2010-12-18 05:57:16 »

Valuable PSAs to heed

http://www.nbc.com/saturday-night-live/video/sexual-harassment/258532/

6

Completely Unrelated / Re: LOL I was cruising around the internet and found a topic about halkun!

« on: 2010-09-28 20:09:42 »

Holy crap Halkun, how many times is it that you've become internet famous now?
http://arstechnica.com/gaming/news/2010/09/the-true-story-behind-the-amazing-minecraft-enterprise-d.ars

7

Completely Unrelated / Re: LOL I was cruising around the internet and found a topic about halkun!

« on: 2010-09-28 05:43:43 »

I watched that just 30 minutes ago. I thought "Halkun?? Could it be? Nah...." 

8

Archive / Re: FF7 PSX videos

« on: 2010-09-18 19:59:47 »

Thanks for your ramblings Cyberman!

Now DCT data is dimensionless (IE it's not constrained to pixel size per sea)

I know how it works etc. but adding data (think of an 8x8 block of pixels that had the DCT performed on them. the DCT is dimensionless data so the block size must be ASSUMED to be or have information that it 8x8), I suppose this is where quarter and sub pixel compression becomes handy for anti-aliasing purposes. 

I was actually pondering this very thing the other day: is there any value trying to scale at the DCT coefficient level? I wasn't sure how it would be possible, but now I see that the DCT equation is indeed dimensionless, so it could use 8x8 for the input matrix, and ANYxANY for the output matrix. I'm really curious what the results will look like. You have given me a lot to explore...

Another thing is simply moving from using integer DCT to a floating point based one can significantly improve the results. I believe the IDCT is a bit loss-y and has enough truncation error it creates other issues with the image data

My thoughts exactly, which is why jPSXdec uses floating-point math for all its operations (quantization, IDCT, etc) in the 'high' quality setting. Now if only it was possible to keep that floating-point fidelity in AviSynth and its filters, then my quality cravings could finally be satisfied.

9

Archive / Re: FF7 PSX videos

« on: 2010-09-17 11:37:31 »

M35

Whilst that does look smoother, it has lost a lot of its detail.  You can get the same result with any number of filters, even inside sony vegas.  The best method seems to be to use your video converter, then place uncompressed result inside vegas and add a few simple filters then export to h.264.

There is always going to be a loss here.  The smoother you go the less detailed but less pixelated.  As it is, the fact is we are working with 320X224 videos and you can't polish a turd

I was looking through this thread to see if any Sony Vegas videos were posted, but couldn't find any. I'd be interested to see what it can do in comparison.

Conceptually, what I posted is about the best I will ever achieve (these points are also addressed in this post):
* PSX outputs YCbCr components with the full JPEG/JFIF/PC.601 [0-255] color range. This should be utilized as much as possible before reducing to the standard Rec.601 [16-235/240] color range, or RGB.
* PSX videos suffer most noticeably from blockiness and ringing artifacts. For best results, these artifacts should be filtered from the original YCbCr image data prior to any other transformation.
* Finally, I wanted to ensure there was no chroma shift because exact chroma positioning can vary.

I want to emphasize that conceptually I think this is the best. This would need careful subjective observation and objective signal analysis to determine if it really is the best. And while I'm no stranger to video technologies, I still know very little about fundamental signal processing theory (e.g. low-pass filters, FFT, etc). Someone with that kind of knowledge might know of even better filtering techniques for this data.

10

Archive / Re: FF7 PSX videos

« on: 2010-09-11 07:46:03 »

I've recently had to remaster some videos from another PlayStation game. As a result, I may have found a technique that maintains the most amount of quality by adding a new format to jPSXdec: pc.601 (a.k.a. jpeg or jfif) YUV (possibly available in v0.93.2+).

Code: [Select]

java -jar jpsxdec.jar ff7disc1.bin -i ff7disc1.idx -d 3472 -quality high -vf avi:jyuv

I then let Avisynth and plugins do the heavy lifting.

Requires Avisynth 2.6 (alpha)
Uses nnedi3 for scaling as suggested by superbbjai, and DGMPGDec for deblocking.

Code: [Select]

# OPENINGE.avs
LoadPlugin("nnedi3.dll")
LoadPlugin("DGDecode.dll")
AviSource("OPENINGE[0].avi")

# Deblocking
# quant is the strength between 1 and 31
# 12 seemed to be good, but the value could certainly be explored
# There is a huge list of similar filters on this page
# http://www.aquilinestudios.org/avsfilters/spatial.html
# which I didn't try
BlindPP(quant=12)

# Scale up by 4x for a final resolution of 1280x896
# The results of nnedi3 appeared slightly bettern than Spline64Resize
nnedi3_rpow2(rfactor=4)

# Convert to RGB mostly to ensure there is no chroma shift later,
# but is only available in 2.6
# matrix is to specify that the input uses the pc.601 [0-255] component range
ConvertToRGB32(matrix="pc.601", chromaplacement="MPEG1")

# ffmpeg likes to flip Avisynth rgba input
FlipVertical()

Then ffmpeg for the encoding.

Code: [Select]

ffmpeg -i OPENINGE.avs -acodec libmp3lame -ab 128k -vcodec libx264 -vpre veryslow -crf 12 -threads 0 OPENINGE.mp4


Code: [Select]

-acodec libmp3lame -ab 128k
Encode mp3 at 128kbps. My Windows binary didn't have aac included for audio, otherwise I would have used that.

-vcodec libx264
Encode video as h.264

-vpre veryslow
Use the best encoding preset

-crf 12
Encode at a constant quality.
Value is usually between 12-24. Lower value is better.
12 is probably overkill for this case.

-threads 0
Use all the processors!

The end result:



Full video
http://www.megaupload.com/?d=LCGPEC6G

I know this can't work with the current PC drivers, but I figured I'd share my work in case someone found it useful.

11

General Discussion / Re: A proposed way to curb wasted time on Ultima ed. or other pirated editions.

« on: 2010-08-27 13:35:02 »

I may be incorrect, but it seems the moderators waste even more time dealing with people who necro threads. I've been on boards where older threads are automatically locked. I don't see why you don't do that, or at least have a large blinking banner whenever you reply to an old thread warning of potential rule violation. But maybe this sort of thing has already been implemented. I haven't necro'd any threads lately.

For the pirated version prevention, the word detection method will probably help. An alternative might be a mandatory question during sign-up with a dropdown box: "Where did you acquire your copy of FF7?" [ebay, Craigslist, pawn shop, Salvation Army, used game store, a friend, The Pirate Bay, Rapidshare, Mega Upload, other download, etc.] Maybe have a box for "If other, please explain..."

12

Completely Unrelated / Re: Stallman busting some moves

« on: 2010-08-15 14:18:49 »

'-._                  ___.....___
    `.__           ,-'        ,-.`-,
        `''-------'          ( p )  `._        HAVE YOU BUSTED
                              `-'      \      SOME MOVES TODAY?
                                        \
                              .         \
                               \---..,--'
   ................._           --...--,
                     `-.._         _.-'
                          `'-----''

13

Completely Unrelated / Re: So, I'm learning C++...

« on: 2010-06-17 05:10:36 »

REAL MEN don't touch any other programming language until they have read SICP and mastered LISP

I would never recommend anyone learn C++ as an introduction to programming, nor would I recommend it as an introduction to OOP. Nearly all the basic concepts can be learned in other languages, without the extra complexity C++ requires you to deal with.

If you already have a little programming experience, then maybe understanding the basics of OOP would be the next step. In that case Java, C# or VB.NET are all much simpler introductions to such concepts.

My suggestion is to learn C++ only after you've established a nice foundation of programming and OOP basics, because you'll spend more time battling the idiosyncrasies of C++ and learning its 'best practicies' (so you don't shoot yourself in the foot with the language) than actually learning much about programming.

But which, in your opinion, is the best to start learning OOP? Java has the advantage of being a decent language to learn in its own right...

I think it depends on exactly what you're looking to learn and do. If you want to just get stuff working, then perhaps C# and VB.NET would be better. They are generally more lenient and flexible than Java in OOP design patterns (some might say that is a bad thing). If you are wanting to take a more disciplined and correct/rigid approach, then Java is probably the way to go.

14

Completely Unrelated / Re: So, I'm learning C++...

« on: 2010-06-16 20:19:27 »

REAL MEN don't touch any other programming language until they have read SICP and mastered LISP

I would never recommend anyone learn C++ as an introduction to programming, nor would I recommend it as an introduction to OOP. Nearly all the basic concepts can be learned in other languages, without the extra complexity C++ requires you to deal with.

Additionally, if you're fairly new to programming, issues such as vendor lockin, proprietary standards, marketability, language flexibility, etc. aren't going to be things you have to worry about anytime soon.

For anyone's first language, I suggest you start with whatever is easiest to pick up--or what meshes best with you (for me is was Borland Turbo Pascal oh some 15 years ago). It doesn't really matter how popular or practical it is, just so long as you enjoy working with it. Most people like to see output as quickly as possible, so maybe C# or VB.NET would be good choices.

If you already have a little programming experience, then maybe understanding the basics of OOP would be the next step. In that case Java, C# or VB.NET are all much simpler introductions to such concepts.

My suggestion is to learn C++ only after you've established a nice foundation of programming and OOP basics, because you'll spend more time battling the idiosyncrasies of C++ and learning its 'best practicies' (so you don't shoot yourself in the foot with the language) than actually learning much about programming.

15

General Discussion / Re: Remember Final Fantasy: The Spirits Within?

« on: 2010-06-11 23:58:29 »

I've been trying to find an HD version of this trailer (which I find more engaging than the movie itself), but without success.

16

Releases / Replacement FMVs for FFVII

« on: 2010-05-16 23:25:39 »

Oh I'm so glad we found an accord   

I never intended to say that all videos report 15 fps in different games (but I certainly didn't know that), although it is news to me that they can use different ones inside the same game.  

Not really important, but I may not have been perfectly clear about this. PSX games can actually use just about any frame rate you can imagine. PSX videos can even have variable frame rates (which took no small effort to include handling for in jPSXdec). FF7 videos just happen to use three particular rates.

17

Releases / Replacement FMVs for FFVII

« on: 2010-05-16 22:23:33 »

OK....me and kranmer have been looking into this.  First, an apology.  Your program does seem to report exactly what I would expect on most of these video's, which is what I said earlier....that they are all 1 frame rate.

(the earlier version of your program was way off on pretty much all of them,

Ah, I assumed you had noticed when I posted earlier about the v0.92.0 update which fixed frame rate detection, and were using that latest version. That would explain why you thought there were "50 different frame rates" (which the older v0.35 inaccurately reported). I'm glad we got that cleared up...except for what I said earlier...that the FF7 PSX still does not use all 1 frame rate. It uses three: 15fps, 15.000/1.001fps, and 18.75fps.

I still cannot explain why there is just 1 vid out here... that is still reporting (as of latest release) an 'odd' framerate of 18.75 fps.

Yes, as you found, SMK.STR and LSLMV.STR both have the different frame rate of 18.75fps. jPSXdec is operating correctly, and is accurately detecting the exact rate on the PSX disc. The rate is very easy to calculate: 150/8 = 18.75. I trust this calculation makes since to you because you must have looked at my documentation by now (something I have twice suggested you do).

All the others are perfect and reporting 14.985 or 15.000 which is correct.
(using 15 fps for that in PC would be what is expected)  

Thank you for accepting them as 'correct', because that is exactly what they are on the PSX. As I've said before, you are welcome to adjust all the videos to be exactly 15fps for the PC version since that's what it needs.


Thank you also for making the full list of videos. I was thinking of doing that myself in order to clear up some of this confusion. Let me annotate it with some additional details.

By Kranmer (marked in red are problems?):

CD1
BIKEGET[0].avi   = 14.985 (has audio)
BISKDEAD[0].avi   = 15.000 (no audio)
BOOGDEMO[0].avi   = 15.000 (no audio)
BOOGDOWN[0].avi   = 15.000 (no audio)
BOOGSTAR[0].avi   = 15.000 (no audio)
BOOGUP[0].avi   = 15.000 (no audio)
BRGNVL[0].avi   = 14.985 (has audio)
CAR_1209[0].avi   = 15.000 (no audio)
D_ROPEGO[0].avi   = 14.985 (has audio)
D_ROPEIN[0].avi   = 14.985 (has audio)
EARITHDD[0].avi   = 14.985 (has audio)
FALLPL[0].avi   = 14.985 (has audio)
FUNERAL[0].avi   = 15.000 (no audio)
GOLD1[0].avi   = 14.985 (has audio)
GOLD2[0].avi   = 14.985 (has audio)
GOLD3[0].avi   = 14.985 (has audio)
GOLD4[0].avi   = 14.985 (has audio)
GOLD5[0].avi   = 15.000 (no audio)
GOLD6[0].avi   = 14.985 (has audio)
GOLD7[0].avi   = 14.985 (has audio)
GOLD7_2[0].avi   = 14.985 (has audio)
HIWIND0[0].avi   = 14.985 (has audio)
JAIROFAL[0].avi   = 14.985 (has audio)
JAIROFLY[0].avi   = 14.985 (has audio)
JUNAIRD[0].avi   = 15.000 (no audio)
JUNAIRU[0].avi   = 15.000 (no audio)
JUNELEGO[0].avi   = 15.000 (no audio)
JUNELEIN[0].avi   = 15.000 (no audio)
JUNIN_GO[0].avi   = 15.000 (no audio)
JUNIN_IN[0].avi   = 15.000 (no audio)
JUNON[0].avi   = 15.000 (no audio)
MAINPLR[0].avi   = 14.985 (has audio)
MK8[0].avi   = 15.000
MKUP[0].avi   = 15.000
MONITOR[0].avi   = 15.000 (no audio)
MTCRL[0].avi   = 15.000 (no audio)
MTNVL2[0].avi   = 15.000 (no audio)
MTNVL[0].avi   = 15.000 (no audio)
NIVLJNV[0].avi   = 14.985 (has audio)
NIVLSFS[0].avi   = 14.985 (has audio)
NORTHMK[0].avi   = 14.985 (has audio)
NVLMK[0].avi   = 14.985 (has audio)
ONTRAIN[0].avi   = 14.985 (has audio)
OPENING[0].avi   = 14.985 (has audio)
PLREXP[0].avi   = 14.985 (has audio)
RCKTFAIL[0].avi   = 14.985 (has audio)
SETO[0].avi   = 15.000 (no audio)
SMK[0].avi   = 18.750 (no audio)
SOUTHMK[0].avi   = 14.985 (has audio)
U_ROPEGO[0].avi   = 14.985 (has audio)
U_ROPEIN[0].avi   = 14.985 (has audio)

You may notice the pattern that all videos with 15.000/1.001fps have audio, and all videos without audio are 15fps (except for the 18.75 cases, which I admit are odd, but still that is how they are). And no, just because there is audio in a PSX movie doesn't mean it will automatically have a fractional frame rate (please see my documentation for details). The PSX game designers deliberately chose those frame rates that you see. My assumption is they used 15.000/1.001fps to prevent the audio from getting out of sync with the video. Why they used 18.75fps for those two videos is a mystery to me.

I am not sure if aali's driver or FF7 PC will manage with 14.985, and hence, an option to round them all to 15 would definately be preferable imho.  I will need to test it...

I will agree yet again that adjusting to 15fps for PC sounds like the best course of action. I hope since we agree on that point, you don't have to persist asserting your still unfounded idea that all the FF7 PSX videos should all be detected as 15fps. In the unfortunate case that you continue to insist that erroneous notion, let me address 3 reasons you have briefly mentioned why you might think that.

1) PsxMC reports 15fps
I have generally avoided ripping on the legacy converters of the past, but frankly, they're pretty shoddy. Everything I've seen about them suggests the authors put little effort in ensuring quality output. In general, what those programs produce is "good enough"--but that's partly why I created jPSXdec--because "good enough" wasn't good enough for me

2) The PC version uses 15fps
I've also avoided pointing out the common knowledge that the PC port of FF7 SUCKED. I'm not surprised that the PC frame rates differ from the PSX version. I assume when the developers needed to generate the AVI files, they just used 15fps for everything simply because it was easier for them at the time.

3) An incorrect frame rate would make the audio/video out of sync
That is correct. However, PSX FF7 videos don't really exhibit the problem because either the movie doesn't have audio, or the movie isn't long enough to expose the audio offset. The final FF7 movie on disc 3 is the longest with audio, but the sync at the end is still pretty small in the worst case.

I will reiterate: I would be most interested in hearing any empirical evidence supporting your claim. If you aren't going to supply any, then please, stop putting jPSXdec quality into question.

18

Releases / Replacement FMVs for FFVII

« on: 2010-05-15 03:44:03 »

Let me clarify that I think replacing the PC FF7 videos is a great idea. I applaud the work of the people trying for the best quality, and I hope my support might help with that.

It sounds like the PC version really needs the videos to be 15fps. If that is the case, then I think the videos on the PC should be 15fps. I don't think this would reduce the quality of the PC version at all. I hope we can agree on this.


What I am having an issue about is the claim that all FF7 PSX videos must also be 15fps. I initially brushed off this idea by simply pointing people at all the research and documentation I've studied for years. Yet for some reason people are still emphatically asserting this bizarre notion, while never supplying any empirical evidence.

I have put a great deal of work into understanding these things so jPSXdec could be the best tool out there. People continuing to stress the PSX 15fps claim are indirectly suggesting that jPSXdec is somehow not getting it right, which undermines the programs credibility. As such, I would like to defend it.

The method one uses to determine if a PSX movie is 15fps, 20fps or 30fps is the same method I used to determine the 15.000/1.001fps and 18.75fps. While I have supplied all the related documentation, I get the feeling people haven't read any of it. Please do. But if that isn't convincing, here is an example: put the final PSX FF7 movie in VirtualDub and tell it to adjust the frame rate to match the audio length. The resulting frame rate is even less than 15.000/1.001. If you try to play the whole thing at exactly 15fps, you might notice the audio become out of sync a tiny bit toward the end.

I would appreciate it if people would stop presuming you know so much about the PSX frame rate without providing any evidence of it. If you do have any evidence you can share, I would be happy to consider it. For example, you might consider the following:

How did you determine the exact PSX fps on the TV? Do the frame counts of all the PC movies match the PSX? Have you compared the PSX and PC movies frame-by-frame? Clearly the audio sample rate is different between the PSX and PC. Have you compared the audio duration between the two? Do the equivalent audio clips line up?

19

Releases / Replacement FMVs for FFVII

« on: 2010-05-13 20:39:26 »

So only colour could be improved?

Therw ill be no improvements to anything else?  I can deal with that....I am not fussed wrangling over a small difference in colour.

I may wait though until there is an option to choose frame rate, and a GUI again rather than command line.  If the quality is likely to remain mostly unchanged, I may go ahead and start converting.

I find it interesting that the PC and PSX versions use different frame rates. I would be interested in learning why the developers chose to do that. The frame rate you want to use in your re-encoding efforts is up to you. I don't assume to know all the details about what you have to do for that task.

I appreciate your jPSXdec feature request (I can count on one hand the number of feature requests I've received), but allowing the user to specify a frame rate that is different from what is on the disc is something I see no demand for beyond your one case. Additionally, jPSXdec will know the PSX frame rate better than the user (in fact, now jPSXdec usually does a better job of it than even I can do by hand), so I don't want to introduce a feature that will most likely just shoot the user in the foot.

In the extremely rare case someone else needs to change the frame rate, there are plenty of other programs out there that can do it (like VirtualDub). In your case, the trick I suggested to search-and-replace in the index files will actually be much easier and faster than having to manually specify the frame rate of every single movie using any GUI, whether jPSXdec or VirtualDub.

Right now perfecting the colors is my top priority, but I can't promise you will see very noticeable improvement. I've also made a little progress on the new GUI, but it's not much a priority since theoretically anyone with Java programming skills could help with that.

I really need a used, early generation (darker gray color) PlayStation, along with an Action Replay or Gameshark that plugs into the debug port. That will give me the critical information I need to continue.

It would be really hard to find that PlayStation because it is the oldest version. But if you have the money try Ebay.

I saw exactly what I wanted on Craigslist a month ago, but it's gone now   I keep hoping something will pop up again.

20

Scripting and Reverse Engineering / Re: TIM files for those starting out

« on: 2010-05-08 04:58:36 »

Thanks for this. Perhaps some of it can be merged with the documentation on the wiki? Also, I don't notice anything about TIMs with an odd width. I included some handling for that case in my (currently unused) library, but haven't ever tested it.

21

Releases / Replacement FMVs for FFVII

« on: 2010-05-07 04:49:11 »

Any case, I am just waiting now to see if this latest FMV extract program is going to get better in the coming revisions with regards to quality...

I don't want to start extracting and encoding only to find it could have been even better

I've spent the last week looking very closely at colors and how they should be handled. It is very complicated, and there won't be any useful update to jPSXdec for some months.

I really need a used, early generation (darker gray color) PlayStation, along with an Action Replay or Gameshark that plugs into the debug port. That will give me the critical information I need to continue.

22

Releases / Replacement FMVs for FFVII

« on: 2010-05-02 08:01:42 »

They are ALL 15 fps.  Even if they aren't reported as it by whatever means you are using.  Every single ff7 video is 15 fps.

They all play at 15 frames in 1 second.  The PSX was designed to play at 15 and 30.

Oh really?   Sorry my friend, but the last 3 years working on jPSXdec have led me to conclude otherwise. Try Tekken 3 in PSmplay for yourself if you don't believe me (20fps movies). jPSXdec just reports what is on the disc. If you have any technical information about this topic, I would certainly be interested in it.

23

Releases / Replacement FMVs for FFVII

« on: 2010-05-02 01:57:31 »

just wanted to let you know that sony vegas can play YUV format, i installed win7 evaluation onto my VirtualBox and then the trial of sony vegas and then ran jPSXdec and encoded the videos to AVI then tried to open them in sony vegas and they only opened as sound files, then i installed k-lite mega codec 590 (the latest at the time i am writing this) and then tried again and it worked. So basicly just install the right codecs and it should work (i thought vegas used its own codecs but i guess i was wrong, maybe thats only for encoding and not decoding).

The videophile in me is suspicious because it's probably just converting to RGB in the background for Sony Vegas. But I could be wrong, and like I said, it may be fine for people who aren't crazy like me.

Also a few of the videos are encoded at way above 15.000fps, for example the video SMK from FF7 is outputed to 18.750fps.

That is correct. There is at least one video on PSX FF7 that doesn't have the 15 (or the NTSC-like variant 15000/1001) fps rate, but is instead 18.75fps.

24

Releases / Replacement FMVs for FFVII

« on: 2010-05-01 07:49:25 »

m35, I exported with highest settings to yuv, and this file wouldn't load in Sony Vegas?  What about exporting to bitmap images again?  Isn't that also uncompressed and top quality?

Are you serious? Sony Vegas doesn't support YV12 color space? That's very disappointing, and now I'm not sure what to suggest.

* Pretty much every good codec (e.g. h.264, xvid, etc.) ultimately wants the video data in a YUV color space. The video data from the PSX disc is already in a YUV color space so I hoped to skip the intermediate RGB step altogether.
* Additionally, I recommended using jPSXdec YUV export because jPSXdec can only perform a very mechanical YUV->RGB conversion, so the quality suffers. Skipping that step saves us from that degradation as well.
* Finally, converting the jPSXdec YUV export to RGB using another program also degrades quality because the YV12 YUV color space is smaller than the RGB color space, so color information is lost in the conversion.

If you need the best quality RGB, it's, well...not available yet. I didn't think I would have to tackle smarter YUV->RGB conversion in jPSXdec because I assumed the simple YUV export would be good enough. But now it seems there are cases where RGB is still necessary. I'll add it to the TODO list, but can't say when or if will be implemented.

The only option right now might be to use another program that can work with YV12 color space.


Note: I'm somewhat of a videophile. There's a chance no one would even notice the degradation of qualities identified above. Try them out. Maybe it will be good enough after all.

25

Completely Unrelated / Re: Sony = Stupid?

« on: 2010-04-27 02:55:43 »

FRNXT GHRT SONY GURM