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.
Recent Posts
3
General - (fb2k) / Re: Running Foobar in Linux
Last post by ThaCrip -
Those having issues with newer versions of Wine. at least on Linux Mint (and the like) a easy fix is just to use Foobar2000 through PlayOnLinux as then you can select older versions of Wine. so from PlayOnLinux's main menu select 'Tools > Manage Wine versions' you select 32bit(x86) or 64bit(amd64) tab and they are contained within their own Wine prefix separate from the standard system installation in a nice easy-to-use manner. currently the newest Wine versions available through PlayOnLinux are... 64bit = 6.17, 32bit = 7.11.

NOTE: I am currently using '6.13-staging' 64bit version for Foobar2000.

with that said... I get it's good to report issues with the newest Wine and all though. but at least as long as older versions continue to work for the foreseeable future, then we ain't got too much to worry about by using the older versions of Wine ;)

p.s. I tend to run my limited amount of Windows programs (Foobar2000/ImgBurn/KProbe etc) through PlayOnLinux, which keeps things separated from the standard system installed Wine and then run the limited amount of games I play through the standard system installed Wine (i.e. ".wine" configuration folder) paired with Lutris and the GloriousEggroll runner for Lutris. this way if anything gets out of whack with the standard ".wine" configuration folder it won't have any negative effect on the PlayOnLinux installed programs.
4
Validated News / Re: TAK 2.3.3
Last post by sPeziFisH -
Thank you Thomas for the new release! Your details about efforts and insights are always a pleasure to read too.

@Future:
of course welcome to also have CPUs of the last decade in view, I guess most of us will run those. Reg. to https://en.wikipedia.org/wiki/Advanced_Vector_Extensions the last 5-7years-generations seems to have AVX2 support, newer CPUs are targeting next generation AVX-512.
My CPU does not have AVX2, next one in the next 12 months will, nevertheless I personally start endcoding and do not watch the progressbar. I rarely take care of some % of encoding as with current enc-speed-range, which is already at an awesome level, this is not the driving factor - to me.
To whom might this be an 'issue' or real downside at all, usecases, scenarios, ..? The group might get smaller and smaller anyway.
IMHO it makes sense to really go for the newer instruction set with next version, which will be sort of minor-version 2.4 then, guess so. And for the almost impossible case of bug fixing release another 2.3.x patch-version of no-AVX2 TAK.

Also like ktf's thoughts.
9
Validated News / Re: TAK 2.3.3
Last post by ktf -
Currently it's not clear what i will do next.

Your website is slightly out-of-date, listing the following items
Quote
    Unterstützung für Unicode-Zeichensätze.
    Eine deutschsprachige Version.
    Noch ein bißchen mehr Geschwindigkeit und Kompressionseffizienz...
    Anwendungen für andere Plattformen als Windows.
    Unterstützung für mehr als 6 Audiokanäle.

  • For FLAC I think there is still a bit to gain by improving quantization of predictor coefficients, but it seems this is not applicable to TAK, as it doesn't store raw predictor coefficients like FLAC does. I'm sharing the idea just in case it does make sense
  • You could consider switching from MD5 to something faster. I've been told most SHA checksums are faster simply because they don't have a long dependency chain and can more efficiently use the superscalar properties and out-of-order execution capabilities of modern CPUs. (That would obviously break backward compatibility, but only for checksumming) For FLAC checksumming is quite a significant part of decoding CPU load (and encoding for the fastest presets), so I imagine this is also the case for TAK.
  • You could consider looking into the arithmetic coder used in Daala/AV1. That is an arithmetic coder that was specifically designed to evade any existing patents. I don't know whether that is fast enough for your liking

Of course I don't know where you would like TAK to go from here. Do you still like to make (big) changes/additions to the format, or do you want to keep things backwards-compatible?

I know you've been talking about open-sourcing, but I can imagine this is a big step. If you'd like to see TAK gain more users, you could consider contributing a bare essentials TAK encoder to ffmpeg for example. I would imagine a TAK encoder without all specific tuning and tweaks, just a simple TAK encoder would already beat FLAC with ease. Or instead of open-sourcing the software, you could open up the format by creating a document describing the structure and sharing the ideas you used. Maybe someone else will do it for you (like the ffmpeg guys did with wavpack)

Please don't feel offended or pressured to do anything, I just wanted to contribute a few ideas.