Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Old 1.x versions usage (Read 6358 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Old 1.x versions usage

Looking at crash report statistics, I have noticed that lots of people still use version 1.6.16, that is last 1.6.x before 2.0.
I understand that some just don't want 2.x features, that's why I made version 1.6.17 - in September 2023 - with important bug fixes - most notably fixes for libwebp exploits. Unfortunately, few people seem to have noticed it, 1.6.16 is still way more popular.
If you're on 1.6.x, please make sure you have the latest iteration of it. Really.

That said, if there are any special wishes for bug fixes (not feature updates) to be backported to 1.6 or 1.5 series, please post them here.
I'm considering backporting of Windows Imaging Component interop from 2.x to 1.6 to get rid of libwebp entirely, then you can't see webp covers on old systems but don't have to worry about updating libwebp with security fixes.
Microsoft Windows: We can't script here, this is bat country.

Re: Old 1.x versions usage

Reply #1
Thank you, @Peter.

I remember the day when I first installed 2.* and immediately felt out of place. Why? Because you broke changed the way portable works  — it is no longer possible to put the player in the custom folder, remove portable_mode_enabled file and (temporary) associate the player with audio files within Shell Integration page, keeping the profile in that folder as well. Users of audio forums were forced to invent tricks like using Windows junction points and writing batch scripts with tons of reg commands to simulate previous behavior. The irony is that there are more customization options like ReFacets (which I hadn't used before, preferring simplicity), but at the same time, you ignored the long-standing habit and imposed a new way of installation. Perfect is the enemy of good, as they say.

Personally, I expected improving the documentation of existing functions (right there, at least in the form of tooltips) in order to reduce anxiety and make the best use of Foobar2000. For example, ReplayGain page is still a mystery, why mono files sound quieter, what is… fast DSP reset, flush playback queue, MMCSS, which music formats are affected by “slow but accurate seeking”, what and where are “dead items” and when is it time to remove them, etc.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Old 1.x versions usage

Reply #2
It's not only about bugfixes or not needing v2 features, but as reported by people being forced to use 32 bit versions yet, v2 forces caching of all tags and it can not be set to skip caching of specific ones. Thus it crashes on big libraries in some cases, as soon as you got lyrics or fingerprints, or things which don't need to be cached at all (for queries usage, etc.).

https://hydrogenaud.io/index.php/topic,125541.0.html

Therefore I'm stuck with v1.6, which allows to manage the mem usage for specific tags if needed.

There is also a recurring crash when trying to play missing/dead files on a playlist, at least in v1.6. Which surely accounts for many of my reports.

EDIT: Btw, until this post, I didn't knew there was a 1.6.17 version. It's currrently so hidden on the download page that most people will simply not notice there is a new (old) version.

Re: Old 1.x versions usage

Reply #3
That said, if there are any special wishes for bug fixes (not feature updates) to be backported to 1.6 or 1.5 series, please post them here.

The ITUNESCOMPILATION value of zero bug, fixed in 1.6.13, was reported both before and after the 1.5.11 release.  But I guess that if a 1.5.12 is on the table, then 1.6 bugfixes will be committed anyway?

Re: Old 1.x versions usage

Reply #4
Please do not debate my design decisions or your specific foobar2000 v2.0+ annoyances here.
If there are known bugs in old versions, please post them replying to this topic.
Thanks for understanding.

There is also a recurring crash when trying to play missing/dead files on a playlist, at least in v1.6. Which surely accounts for many of my reports.
Can you please share specific crash log+dump from your computer please? I'm having trouble identifying relevant reports. Can the problem be reproduced on a clean portable install?

The ITUNESCOMPILATION value of zero bug, fixed in 1.6.13, was reported both before and after the 1.5.11 release.  But I guess that if a 1.5.12 is on the table, then 1.6 bugfixes will be committed anyway?
OK, merged both ITUNESCOMPILATION fixes to 1.5.x source, will release 1.5.12 with these fixes eventually.
Microsoft Windows: We can't script here, this is bat country.

Re: Old 1.x versions usage

Reply #5
As Case points out in https://hydrogenaud.io/index.php/topic,123198.msg1044196.html#msg1044196 , this old ffmpeg will bug decoding MPEG-2 layer 3. 
There have been other decoding bugs in ffmpeg too, I guess fewer fb2k user will attempt directing WavPack nor FLAC decoding through ffmpeg, and those bugs are also "rare" - the FLAC decoding bug is not fixed, there is a link to a patch in the librempeg fork.

Re: Old 1.x versions usage

Reply #6
MPEG-2 layer 3 glitch has been fixed for upcoming 1.x refresh, thanks for bringing this up.

In foobar2000 prior to 2.0, only formats decoded thru FFmpeg are: MP3, Vorbis, AAC, ALAC
Bugs in FFmpeg not affecting these are not relevant.
libavformat is entirely disabled, libavcodec packet decoding is used only.
(Vorbis decoding was moved back to libvorbis in 2.x series)
Microsoft Windows: We can't script here, this is bat country.

Re: Old 1.x versions usage

Reply #7
New updates have been published.

Highlight of the day is that all of 1.5 stable had unintended SSE2 CPU requirement and we didn't notice until now.
It was inflicted by VS runtime update, introduced shortly after testing late 1.5 beta on a Pentium 2.
This has now been sanitized, foobar2000 1.5.12 has been verified working on Athlon XP machine from 2003.
Microsoft Windows: We can't script here, this is bat country.


Re: Old 1.x versions usage

Reply #9
Thanks a lot for updating 1.6 series!!!

Re: Old 1.x versions usage

Reply #10
This explains why it kept crashing in 86box when attempting to play or load something.  Now it plays and loads without crashing.  Emulating an old Pentium II with XP Service Pack 3 installed in the screenshot below.  Ran it out of curiosity a while back.  Figured it had something to do with SEE2 instructions not being supported.  And no, this is not how I normally listen to music as I simply wanted to see if foobar2000 1.5 series could actually run inside 86box which doesn't emulate any hardware newer than the year 1999.

Re: Old 1.x versions usage

Reply #11
I have been experiencing a problem playing files in foobar2000 for a long time and I thought it was some inadequacy on my part, which is why I stopped speaking out here.

However, I am almost convinced that this is not a personal mistake. Every time I access foobar2000 directly from File Explorer (Windows 10 x64) where a certain directory contains more than 15 songs, the player does not open to play the files. To do so, I open a directory and click on the "Play all" command in File Explorer. Any directory with up to 15 tracks this command works correctly.

Currently, I am using version 1.6.18, portable, and all audio file extensions on my system are configured to open with foobar2000.

Re: Old 1.x versions usage

Reply #12
However, I am almost convinced that this is not a personal mistake. Every time I access foobar2000 directly from File Explorer (Windows 10 x64) where a certain directory contains more than 15 songs, the player does not open to play the files. To do so, I open a directory and click on the "Play all" command in File Explorer. Any directory with up to 15 tracks this command works correctly.
You're running into the Windows limitation where there is a 15 file open limit in the context menu handler by design.  Check out https://learn.microsoft.com/en-US/troubleshoot/windows-client/shell-experience/context-menus-shortened-select-over-15-files

The workaround/fix is discussed here:
https://www.tenforums.com/tutorials/94513-fix-context-menu-items-missing-when-more-than-15-selected-windows.html


Re: Old 1.x versions usage

Reply #13
The proper solution would be to not use portable version.

Re: Old 1.x versions usage

Reply #14
OK. Thank you all very much for your enlightening responses!

EDIT: I made the suggested registry modification and now the portable version effectively opens as many files as I determine.