VideoHelp Forum
+ Reply to Thread
Results 1 to 6 of 6
Thread
  1. VideoHelp website has older versions of Foobar2000 archived for download, but where can I find an archive of older versions of Foobar2000 plugins for download? The Foobar2000 website does not have links to download anything but the LATEST version of each plugin. It would be nice if they had a set of links for older versions of each plugin, but it appears that they don't. Is there any site on the net dedicated to the latest archiving all versions of Foobar2000's pluguns (such as foo_sid, for playing Commodore64 music)?
    Quote Quote  
  2. I'm a MEGA Super Moderator Baldrick's Avatar
    Join Date
    Aug 2000
    Location
    Sweden
    Search Comp PM
    I haven't seen any such site.

    https://gitlab.kode54.net/kode54/foo_sid/commits/master has old versions for foo_sid...but ONLY the source code.
    Quote Quote  
  3. I'm a MEGA Super Moderator Baldrick's Avatar
    Join Date
    Aug 2000
    Location
    Sweden
    Search Comp PM
    archive.org is fantastic.

    You can also get different builds from foo_sid using http://web.archive.org/web/20110818024017/http://kode54.foobar2000.org/ (change date at the top)
    Quote Quote  
  4. Thanks. However, I managed to hack the plugin to make it work. I didn't want to have to upgrade my Foobar, just to support a newer version of a plugin sid_foo that had worked before on my current version of Foobar, and this was just a new version of sid_foo, not a plugin for an entirely new file type. Considering that it probably didn't have any new features that would be incompatible with my current version of Foobar, and that the incompatibility error was probably just because the newer version of the plugin had been created in newer version of the Foobar plugin SDK, I decided to try to alter the plugin itself. Unfortunately, this was anything but simple. To do this hack, it required that I run Foobar2000.exe in a debugger (I used Ollydbg) and then look to see where the code was that was responsible for loading the plugins, and triggering the error message box to pop-up if a plugin used too new of an SDK. Fortunately, I've been learning some assembly language, so I was actually able to understand the assembly code that was the output of the debugger. I then put a breakpoint just before here (just before the version compatibility test) and managed to find where in the DLL file that foobar was looking for the plugin's SDK version number, as well as the number that Foobar itself was checking the plugin's version number against. This allowed me to then directly edit the correct byte in the DLL file that was the sid_foo plugin, so that it would report an SDK version number that Foobar would accept, when Foobar queried the plugin for its SDK version number. So now I'm using this hacked version of the sid_foo plugin, and as I expected it works perfectly.

    Now why did I go to all the trouble to reverse engineer and hack the plugin? Simple. I don't want to upgrade software that is already working just fine as it is. Foobar2000 is already working just fine, and I don't want to break it by upgrading it. ANY time you upgrade software, you can potentially break it. And even if it doesn't break, a newer version might have a different GUI, and I like the look-and-feel of Foobar as it is right now. I don't want to risk getting a newer version of it, if I might not like the newer version. But I DID want to make sure the sid_foo plugin was up to date, because the new version of it had some features I liked (able to emulate 2 different models of SID chip), so getting the plugin, and then hacking it to make it work on the older version of Foobar was my only choice.
    Quote Quote  
  5. I'm pretty sure you can install a newer version of foobar2000 as a portable application for testing and leave your current foobar2000 installation untouched.

    http://www.foobar2000.org/releasenotes/11

    Or do you still have the installer for the version of foobar2000 you're currently using? If so you should be able to back up the configuration files and DSPs etc. before upgrading and if you don't like the latest version you can re-install the old version and restore the old configuration files. I don't recall the GUI changing after upgrading the 0.9 version to 1.1.

    For XP, and for the current foobar2000, the configuration files are located in:
    C:\Documents and Settings\User Name\Application Data\foobar2000\

    Just back up the entire foobar2000 folder, assuming the old version keeps the configuration files in the same place (I'm pretty sure it does), but I've used that method after installing foobar2000 on different PCs several times, and after copying over the configuration files, the new installation is exactly the same as the original one.

    Off the top of my head, the newer foobar2000 can adjust the volume of MP3 and AAC audio losslessly using ReplayGain data (as MP3Gain does) and it uses the newer R128 algorithm for ReplayGain scanning, which seems a bit more accurate than the original ReplayGain algorithm. It can tag almost any file format (including wave files and raw AAC) and TagBox is worth a look. It has better re-sampling and downmixing DSPs, it natively decodes audio in MKV/AVI files, ffmpeg has been updated for decoding several times....

    I think by default the newer versions put third party DSPs in the application data folder and only "native" DSPs are kept in the folder where foobar2000 is installed, but that might be the biggest change. I'd recommend upgrading, especially if there's an issue having to run old/obsolete DSPs.
    Last edited by hello_hello; 8th Jun 2016 at 19:06.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!