Recommended Posts

Oi vey. He wouldn't compare it to the GBA or N-gage since neither is a competitor, in the same bracket, to the PSP. The DS and PSP are dueling consoles and, thus, Dazzla decided to use the DS as a basis for some very simple observations regarding the size of the unit, the screen, and some OS basics. Just because the PSP comes off looking better to some of us, doesn't mean you need to get all worried.

585157413[/snapback]

Wrong.. Gizmondo and PSP can compete more than DS, ds is worse than Gizmondo

Has anyone though of cracking the UMD casing open, and putting the disc in a CD-Rom drive?  See if it reads?  I have a strange feeling UMD is just a mini dvd in a case :s .

585502160[/snapback]

I thought thats exactly what it was, a 1.8gb mini DVD.

Prob is, even if comp does read it, then what?

Unfortunatley, we cant buy blank ones to write own own info to to put in the PSP.

Plus I think its a bit early for PSP Emulators! LOL :D

The original reviewer wrote the following regarding encoding video to the PSP: "Full screen is the option I use all the time, it makes the movie touch the borders of all 4 sides. If you convert a 16:9 movie into 320*240 then use full screen it will stretch it back out and retain the correct ratio."

The advice the reviewer gives is in direct conflict from what I have heard througout the net and several other forums. I'm not saying he is wrong. As a matter of fact, I am ready to believe his view over others as his review was very thorough and well put together.

One of the main reasons other than gameplay on why I want the PSP so bad is because of its video playback capability. Prior to focusing in on the PSP, I was in the market for a Personal Video Player, machines that look like the PSP, but carry 20-40 Gb harddrives and work off of microsofts media center software. They are priced anywhere from $450-$1000, so you can see why I am really excited about the PSP.

Anyways, I have already ripped several of my DVD's (ALL widescreen) and have used two encoding programs (raPIZ & 3GP) to get them in the proper MPEG-4 format so the PSP will recognize them.

As everyone knows, the PSP's screen native resolution is 480X272, a 16:9 ratio widescreen format. Everyone also knows that the PSP will not accept any video playback in it's native resolution. Here is where I have questions.

The reviewer states that when encoding a widescreen movie (16:9 ratio), encode the movie at a standard screen resolution of 320X240. If you do this and then set the PSP's screen option to "FULL", the movies will be stretched to fit the screen, and the movie will retain the correct ratio. There is where I would like to expound a little.

If you encode a movie to format of less than 16:9, and then stretch it to fit a 16:9 ratio, how would you be able to retain the correct ratio? The general consensus on this subject in some other forums I visit was that you could "hack" the PSP as it were into recognizing widecreen resolutions, just not it's native resolution of 480X272. One of the encoders I use, raPIZ, has a screen resolution option of 368X208. I have been told that it would be better to encode all movies in this widescreen resolution as when it plays back on the PSP, it will be able to uilize the entire screen, and will retain its correct ratio and not look stretched.

Sorry for being so long winded. I am not saying anyone is wrong here. Not having a PSP of my own to test this out definitively, I am left to the advice of those that have imported them.

That said, if the reviewer or anyone else that has experience with movie playback on the PSP could expound a bit on getting 16:9 movies to playback on the PSP using the entire screen and retaining it's correct ratio. Thanks so much!

Firstly, I have heard that there is an updated version of a encoding prog that now converts to correct ratio, res etc. Hopefully this is true.

Secondly, I have a widescreen tv, and when the tv pic isnt widescreen it shows it with black bars down each of the left n rught side, however you can force the picture to use all of the screen, but then you may lose a bit of the picture as the tv trys to keep everythin in perspective, thats jus my tv though. reason I am tryin to use my tv as an example is i think the psp does exactly the same thing.

I encoded a episode of friends, and when on the psp, it showed it only using part of the screen, with the black borders as previously mentioned. the zoom options I had were, normal, full screen, zoom, and one other cant rem wat called.

Dunno if this helps or not, its jus my take on it. Hopefully this software update is out there and we can all encode happily utilising the fullness of the psp screen! :)

Firstly, I have heard that there is an updated version of a encoding prog that now converts to correct ratio, res etc. Hopefully this is true.

Secondly, I have a widescreen tv, and when the tv pic isnt widescreen it shows it with black bars down each of the left n rught side, however you can force the picture to use all of the screen, but then you may lose a bit of the picture as the tv trys to keep everythin in perspective, thats jus my tv though. reason I am tryin to use my tv as an example is i think the psp does exactly the same thing.

I encoded a episode of friends, and when on the psp, it showed it only using part of the screen, with the black borders as previously mentioned. the zoom options I had were, normal, full screen, zoom, and one other cant rem wat called.

Dunno if this helps or not, its jus my take on it. Hopefully this software update is out there and we can all encode happily utilising the fullness of the psp screen! :)

585516218[/snapback]

Hulibecker, that's my point exactly. I have an HDTV as well, and when I am watching normal 4:3 TV, it has the vertical black bars, but I can set my TV to 16:9 mode wich fills up the entire screen, but, you lose the original picture ratio, and everyones heads are fat, etc, as the picture is being stretch horizontally.

That was my question in reference to the reviewers post. He says encode and 320X240, and then stretch the movie to fit the screen, and if the movie you encoded was in widescreen, the stretched image will not be distorted. At least that is what I took him to say.

If that is true, then I was wondering why on other boards people are "hacking" different resolutions for the PSP trying to attain as close to a "widescreen 16:9" image as they can.

Am I as clear as mud on this, lol?

Anyhow, any and all comments and responses to my questions would be greatly appreciated!

The hacking thing which has recently come about isn't anything to do with ratios, it's about perceived quality. People are trying to get more vertical detail in their encodes because the full screen option stretches horizontally more than vertically. It makes sense to add as much vertical resolution into the video file as you can (to an extent).

View a 16:9 movie at 320*240 and it will be squashed up vertically (the opposite to 4:3 on a HDTV), using full screen will stretch it back up to the right ratio but stretching from 320 -> 480 is less than desirable than stretching a 368px wide movie (this being the "hack" which has recently come about). Either way every pixel of the video is stretched to fill the entire screen in "full screen" mode so what was originally a 16:9 video will still be 16:9 regardless of which "new" encoding size you choose.

From now on I will be encoding into something like 368*208, nothing to do with aspect ratio you understand but the perceived increase in quality due to 368 -> 480 being better than 320 -> 480. Both will result in the original 16:9 movie being 16:9 o the PSP screen when viewed in full screen.

As for wider than 16:9 movies, i.e. 2.35:1 I used to add black borders to the file via virtualdub so it was a 16:9 movie file with borders.

The hacking thing which has recently come about isn't anything to do with ratios, it's about perceived quality. People are trying to get more vertical detail in their encodes because the full screen option stretches horizontally more than vertically. It makes sense to add as much vertical resolution into the video file as you can (to an extent).

View a 16:9 movie at 320*240 and it will be squashed up vertically (the opposite to 4:3 on a HDTV), using full screen will stretch it back up to the right ratio but stretching from 320 -> 480 is less than desirable than stretching a 368px wide movie (this being the "hack" which has recently come about). Either way every pixel of the video is stretched to fill the entire screen in "full screen" mode so what was originally a 16:9 video will still be 16:9 regardless of which "new" encoding size you choose.

From now on I will be encoding into something like 368*208, nothing to do with aspect ratio you understand but the perceived increase in quality due to 368 -> 480 being better than 320 -> 480. Both will result in the original 16:9 movie being 16:9 o the PSP screen when viewed in full screen.

As for wider than 16:9 movies, i.e. 2.35:1 I used to add black borders to the file via virtualdub so it was a 16:9 movie file with borders.

585516757[/snapback]

Well, that is the most intelligent and articulate post I have seen on this question.

You cannot imagine how many people and how many forums I have asked this questions with no real answer.

One last question. You did say that you would in fact be encoding at the 368X208 not so much for how the movie will fit the PSP's screen, but do to the effect that you will have more vertical resolution, which I can understand.

I have encoded movies in both the 320X240 and 368X208 modes. The one difference that I can see for sure is the movie itself. By that I mean when I play the 320X240 movie in quicktime, the movie plays perfect in a 16:9 ratio. However, when I play back a movie encoded in 368X208, the movie plays back like a 2.35:1 movie would on an HDTV, that is, it is widescreen, but still has horizontal black bars above and below the movie.

My question is, when you play a movie encoded in 368X208 on the PSP, and then play it stretched under full mode, will you have those same horizontal black bars above and below the movie???

Thanks again!!!

The only reason why I keep asking these questions trying to get this right is because I would like to have about 10-15 of my movies encoded and ready to go when the PSP launches.

As you know, it is very time consuming to rip and then encode these movies, so before I go through all of the trouble, I just want to make sure that I am encoding these movies properly.

I certainly want the movies to look the best they can, and I also would not like black bars on my PSP while I am watching the movies as well.

Thanks for your help!

Ok, well I gave it a try. I used 3GP Converter 0.29, it has the added options for 368*208. To be really honest, I don't see a huge difference in quality, there is an increase though, so I imagine I'll be using 360*208 in the future. One of the main reasons is that whatever the hack/patch does to enable this it automatically expands the video to fill the PSP screen. It still stretches, it's not native, but it's more convenient. As a consequence it's useless for 4:3 content but cool for 16:9. Only for ease of use you understand though.

320*240. The reason for this is that using the hack causes the video to instantly fill up the screen, and any option you choose on the PSP (Full screen, zoom etc) doesn't effect it. With 4:3 content it would force it to stretch to the screen if you used 368*208. With 320*240 you will have the various stretching options.

320*240. The reason for this is that using the hack causes the video to instantly fill up the screen, and any option you choose on the PSP (Full screen, zoom etc) doesn't effect it. With 4:3 content it would force it to stretch to the screen if you used 368*208. With 320*240 you will have the various stretching options.

585540477[/snapback]

Will there be vertical black bars if I encode with 320x240?

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • BrowserOS 0.46.0 by Razvan Serea BrowserOS is a free, open-source Chromium-based browser that runs AI agents natively, offering a smarter, more productive browsing experience. It supports Chrome extensions and integrates AI agents to automate tasks, fill forms, and streamline workflows. Your data stays on your computer: you can use your own API keys or run local models via Ollama, making it a privacy-first alternative to tools like Perplexity, Comet, or Dia. With built-in productivity tools and app integrations, BrowserOS boosts efficiency while keeping control firmly in your hands. Being Chromium-based, BrowserOS lets you effortlessly import your bookmarks, passwords, and Chrome extensions in just a few clicks. BrowserOS works with OpenAI GPT models, Anthropic Claude, Google Gemini, and local AI models via Ollama or LMStudio. You can use your own API keys and effortlessly switch between providers. BrowserOS Agent Your AI productivity assistant that organizes and manages your browsing effortlessly Quickly list, group, or close tabs Save and resume browsing sessions Search your history and organize bookmarks Switch instantly to the tab you need BrowserOS Navigator – Automate web tasks with ease Navigate websites and search automatically Interact with pages without manual effort Handle repetitive tasks in seconds What makes BrowserOS special Feels like home - same familiar interface as Google Chrome, works with all your extensions AI agents that run on YOUR browser, not in the cloud Privacy first - bring your own keys or use local models with Ollama. Your browsing history stays on your computer Open source and community driven - see exactly what's happening under the hood MCP store to one-click install popular MCPs and use them directly in the browser bar (coming soon) Built-in AI ad blocker that works across more scenarios! BrowserOS 0.46.0 changelog: Run Claude Code & Codex right in your browser — We've extended the agent harness to bring full coding agents into BrowserOS. Claude Code and Codex now come bundled and plug straight into the assistant, so you can drive your browser with the agent — and the subscription — you already use. A brand new experience — A redesigned new tab, a calmer composer, and a rebuilt command center for switching between agents. The whole assistant is cleaner, faster to reach, and easier to live in. New MCP tools — We rebuilt the browser tool surface from the ground up — a tighter, more reliable set of tools for agents to drive the browser. Plus one-click install of BrowserOS as an MCP server into the agents you already run, with automatic URL sync. Chromium 148 — Updated to the latest Chromium base with all recent upstream fixes and security patches. Streamlined — We've pulled back a few features that weren't getting much use — Skills, Soul, and Memory — so we can focus and ship better versions of them soon. Download: BrowserOS 0.46.0 | 181.0 MB (Open Source) Download: BrowserOS for macOS | 485.0 MB Links: BrowserOS Homepage | Github | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Microsoft finally admits its default Windows 11 25H2, 24H2 action broke key legacy component by Sayan Sen Microsoft last week released Windows 11 KB5094126 and KB5093998 as the latest Patch Tuesday updates. Following that the company also published the accompanying dynamic updates under KB5094149, KB5095971, and KB5094156. So far the company has acknowledged two known issues that have popped up after the release which include bugged-out Office apps as well as the Recycle Bin; though there could be more at play too. Speaking of bugs and issues, Microsoft seems to have finally acknowledged a problem that probably has been around for close to a year. That's because back in July of 2025 the company made a default change to the latest Windows 11 versions, wherein it switched to JScript9Legacy on Windows 11 24H2 and later releases. Hence following the release of version 25H2 in October 2025, JScript9Legacy also remained default-enabled. As a result there has been a compatibility issue ever since then. For those wondering, by switching to JScript9Legacy Microsoft intended to improve the security of modern Windows PCs by reducing vulnerabilities tied to legacy scripting like cross-site scripting (XSS), among others. XSS exploits can allow cyber-attackers to attach malicious code onto legitimate websites and use them to execute the code when a potential victim loads such a website. Hence the new JScript9Legacy engine enforced stricter execution policies and improved object handling, which should help mitigate such attacks. Microsoft today has published a new support article detailing the problem. Neowin spotted it while browsing. The company says that JScript global definitions and execution context may fail to persist across scripts, potentially breaking older dependent apps and web-based components that relied on this legacy behavior. In the article Microsoft has confirmed that the issue stems from its move away from the older jscript9.dll engine in favor of jscript9legacy.dll. As mentioned above, while the newer engine was designed to address vulnerabilities and strengthen security it also changes how JScript handles execution context. As a result functions and definitions loaded by one script could no longer remain available to subsequent scripts once execution ended. The company notes that some applications worked correctly on earlier Windows versions because the older JScript engine automatically retained global definitions and execution state between scripts. Under the newer model though that behavior is disabled by default causing certain legacy workloads and polyfill-dependent scripts to fail. Microsoft says it addressed the problem via the KB5077241 update though the fix had not been enabled automatically in the following updates. As such admins must explicitly turn on persistent JScript execution context using a Registry setting that the tech giant shared today. The configuration can be applied to individual processes or system-wide through the FEATURE_ENABLE_PERSISTENCE registry key. The steps have been outlined below: Run the following command to create the feature control registry key: reg add "HKLM\Software\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PERSISTENCE" Under this key, create a new DWORD (32-bit) value. Configure the value as follows: To enable persistence for specific processes only: Set the value to 1 for each target process name. To enable persistence for all processes: Add * as the key name and set its value to 1. You can find the official support article here on Microsoft's website.
    • The possibility that milk gathers back into a glass implies that gravity can be 'reversed'.
    • VidCoder 12.20 by Razvan Serea  VidCoder is a DVD/Blu-ray ripping and video transcoding application for Windows. It uses HandBrake as its encoding engine. Calling directly into the HandBrake library gives it a more rich UI than the official HandBrake Windows GUI. VidCoder can rip DVDs but does not defeat the CSS encryption found in most commercial DVDs. You’ll need the NET 8 Desktop Runtime. If you don’t have it, VidCoder will prompt you to download and install it. The Portable version is self-contained and does not require any .NET Runtime to be installed. You do not need to install HandBrake for VidCoder to work. Feature list: Multi-threaded MP4, MKV containers Completely integrated encoding pipeline: everything is in one process and no huge intermediate temporary files H.264, H.265, MPEG-4, MPEG-2, VP8, Theora video Hardware-accelerated encoding with AMD VCE, Nvidia NVENC and Intel QuickSync AAC, MP3, Vorbis, AC3, FLAC audio encoding and AAC/AC3/MP3/DTS/DTS-HD passthrough Target bitrate, size or quality for video 2-pass encoding Decomb, detelecine, deinterlace, rotate, reflect, chroma smooth, colorspace filters Powerful batch encoding with simultaneous encodes Customizable Pickers to automatically pick audio and subtitle tracks, destination, titles and more Instant source previews Creates small encoded preview clips Pause, resume encoding VidCoder 12.20 changes: Updated HandBrake core to 1.11.2. Download: VidCoder 12.20 | 47.0 MB (Open Source) Download: Portable VidCoder 12.19 | 89.3 MB Link: VidCoder Home Page | Github | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
  • Recent Achievements

    • Week One Done
      Jordan Smith earned a badge
      Week One Done
    • Reacting Well
      BizSAR earned a badge
      Reacting Well
    • First Post
      AndreaB earned a badge
      First Post
    • Week One Done
      Huge Trailer earned a badge
      Week One Done
    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      590
    2. 2
      +Edouard
      185
    3. 3
      PsYcHoKiLLa
      76
    4. 4
      Michael Scrip
      73
    5. 5
      Steven P.
      66
  • Tell a friend

    Love Neowin? Tell a friend!