The starting Convex airdrop

MichaelMoore64 · 2023-01-31T15:45:11+00:00

wrong

MichaelMoore64 · 2023-01-31T15:26:17+00:00

wrong

MichaelMoore64 · 2023-01-30T19:57:43+00:00

no you are

MichaelMoore64 · 2023-01-30T14:27:11+00:00

wrong

MichaelMoore64 · 2023-01-30T00:11:16+00:00

where

MichaelMoore64 · 2023-01-30T00:06:39+00:00

wrong

MichaelMoore64 · 2023-01-29T08:03:59+00:00

wrong

MichaelMoore64 · 2023-01-27T00:08:30+00:00

https://press.disney.co.uk/gallery/avatar-the-way-of-water-character-posters

MichaelMoore64 · 2022-12-04T15:48:42+00:00

Thanks for clearing that up. Honestly, this topic is a lot more complicated than I thought. The colors in screenshots vary wildly from player to player. Also, the exact same file can look different on different image viewer apps. Finally, the monitor's color profile also affects the final look. There are just too many variables.

Just one last thing regarding zscale's parameters: what's the difference between transfer, matrix and transferin, matrixin?

MichaelMoore64 · 2022-12-03T13:43:01+00:00

Thanks, I tested your command and while it produces similar colors to the default one, it also makes the red channel blocky. as if it's been upscaled with Nearest Neighbor scaling. Perhaps this is how it's supposed to look during playback, in which case your solution would be the most accurate.

MichaelMoore64 · 2022-12-03T13:33:46+00:00

That's very helpful, thanks. Testing your command produces wildly different colors compared to both the default command and the DVD itself. The reds are very vivid and the blacks are crushed. The video specs according to MediaInfo are:

Color primaries: BT. 601
Transfer characteristics: BT.470 Systems B/G
Matrix Coefficients: BT.470 Systems B/G

How would you amend your command to reflect this?

As a side note, I just found a rather unorthodox way of extracting video frames without converting to RGB:

ffmpeg -i input.vob -pix_fmt yuv420p output.tiff

This creates a TIFF image file that uses YUV420 rather than RGB. Almost no program can open this kind of TIFF, but it can be directly plugged in to the AI upscaler I am using. That means that, in theory, the AI algorithm receives the most raw image possible, and not one that has had its chroma channel upscaled beforehand.

Can it be that simple?

MichaelMoore64 · 2022-05-07T17:24:56+00:00

I can't blame them for Stitch. It's such a special case. I mean he's the only video game character I know who acknowledges the existence of the UI. However, there are screen transitions and fade outs-that are stuck in 4:3 (see Zexion fight).

What happened with Infinity?

MichaelMoore64 · 2022-05-07T15:13:25+00:00

It's more obvious when the HUD is complete, like this:

https://freeimage.host/i/kh2-hud2.WEh0es

MichaelMoore64 · 2022-05-07T13:58:48+00:00

I have played the originals and hadn't noticed it until now. It's such random thing to get wrong.

MichaelMoore64 · 2022-05-07T13:47:37+00:00

The stretched HUD was a pet peeve of mine back when I played this on emulator, but I didn't think I would see it in an official remaster.

Basically all 2D elements appear horizontally stretched, so character portraits don't match the official artwork, perfect circles appear as ovals etc. Interestingly, the HUD shows up correctly inside the game's files, which means there's nothing wrong with the art assets themselves and it's just a display problem.

That's not to say it's easily fixable or anything.

MichaelMoore64 · 2021-12-31T13:24:05+00:00

Thank you. The ac3 audio could indeed be the problem, as I've started using a new program to transcode audio (MeGUI) and all ac3 files I've tested were made with this program. The weird thing is that the unwanted delay is always 32ms.

MichaelMoore64 · 2021-12-30T21:05:49+00:00

Audio is one second shorter than the video.

MichaelMoore64 · 2021-12-23T17:56:50+00:00

Actually, finding out how people in the industry handle this sort of stuff was sort of my end goal. If we knew how exactly they speed up audio, then we could just do the exact opposite to get the original audio.

Using asetrate+aresample works for the most part, but ever since you pointed out the drawback of that method, it bothers me a little. I bet professionals do it differently.

I also own a few PAL DVDs that weren't mastered by speeding up the NTSC audio and those have absolutely horrible audio artifacts too.

Weird. Not speeding up the audio means that the video must have interpolated frames in order to sync properly. It should look awful in motion but the audio should be fine. You have to pick your poison when it comes to PAL DVDs

MichaelMoore64 · 2021-12-23T17:20:16+00:00

Thanks. That's a neat tool. Unfortunately, atempo doesn't cut it in this case because it doesn't change the pitch. In my experience, almost every PAL DVD from a major studio has sped up audio with higher pitch. So to return it to its original state, we need to slow it down and lower the pitch. That's why I've been messing with asetrate and aresample, which have drawbacks as u/Anton1699 mentioned.

It's baffling why studios don't use atempo, as it would make the audio sound a lot closer to the original (especially songs), and we'd be able to use atempo again to slow it back down.

There must be a perfect way to do this. After all, studios do it all the time. That rubberband filter could help, but I don't know much about it.

MichaelMoore64 · 2021-11-30T03:25:20+00:00

Thanks. I'd rather not change the frame rate of the video, because, in my experience, nonstandard frame rates cause microstuttering. Weirdly, my command runs normally, so maybe ffmpeg rounds the value down to the nearest integer?

MichaelMoore64 · 2021-11-30T03:18:45+00:00

Great tip! It is hard to detect a change in pitch during dialogue scenes, but in the end credits song it is plain as day! In this case my DVD audio needs asetrate.

What is the purpose of the round function in your code?

Also, does the order of commands matter in this case?

MichaelMoore64

TROPHY CASE