Subjectively. Objectively, there's no audible difference between lossy and lossless (at usual bitrates).
126 karma · joined May 20, 2020
Subjectively. Objectively, there's no audible difference between lossy and lossless (at usual bitrates).
Also the whole "you can hear more with lossless audio" is just straight up a lie.
The reason VR enthusiasts want wide FOVs is not because they want to watch movies stretched to 120°. Nobody does that. They want wide FOVs because even at relatively high FOV, like the 106 of Quest Pro, the edges of the display are still easily visible and the image does not fill eye's FOV fully. Yes, the resolution of what we can see towards the edges of our vision are much lower than what we can see in the center, but it's about getting rid of the visible boundry that messes with immersion.
(I'm not aiming that comment at you, but rather at developers making software less and less configurable)
>...How did you calculate a factor by which lossless is better than lossy?
>I specifically typed accurate, not better.
Yeah OK, that's just wording. Which two factors did you specifically compare, that gave you the 8-12x figure?
How did you calculate a factor by which lossless is better than lossy?
Debanding has been a thing for many years now, for frameservers (Avisynth, Vapoursynth), video players (madvr, mpv) and games (reshade), and it certainly didn't require AI to work.
Now in comes this company and introduces such a basic feature, while boasting about it as if it's the second coming of Einstein or something. And it uses AI, because of course it does, it's 2022 after all.
LOL.
> Question: are there any encoders that when encoding M2 to produce C2 can be given M1 and C1 as references using them to adjust I-frame spacing so as make as many C2 I-frames as possible match C1 I-frames?
I suspect if you were to encode both files with x264 with identical settings, in crf mode, with vbv disabled and keyint=0 (unlimited keyframe length), its scene detection should place I-frames in the same places (that is, on scene cuts, not on the timeline). Maybe some scenecut tuning would be necessary.
> That would allow C2 to be stored efficiently as a binary diff from C1. This could be handy if C1 and C2 needed to be checked into a version control system, or you needed to distribute C2 over a low bandwidth or expensive link to someone who already had C1.
I'm not aware of any automated way to do that, but you can do a similar thing manually using mkv's ordered chapters. You first compress the original cut, then you compress any additional scenes and insert them where you need. For example, you can make a mkv file for a theatrical cut of a movie, and then make a separate file for a director's cut that is only as big as the additional scenes are, since it uses the theatrical cut file for the common scenes.