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
1
General - (fb2k) / Re: [Linux] Avoiding re-sampling of Foobar playback?
Last post by Atronach -
Quote from: agentt on
pulseaudio occupies HW:0,0  so it disappears from foobar devices list. better to del pulse
i use wine alsa + wasapi push mode
in linux wasapi exclusive (EVENT) say output busy (Device in use)
i believe wasapi push is good for linux. coz alsa HW:0,0 is always exclusive  :)

That did the trick. winealsa + WASAPI plugin in push mode to be exact. winepulse and/or WASAPI plugin in event mode is no go like you said. Thank you.
2
3rd Party Plugins - (fb2k) / Re: Playlist-Tools-SMP
Last post by regor -
Well... definitely it's not the same to look for something when you have been working on it for months than being totally new to it. So even if it seems "obvious" to me where things are located or what they do, it helps to see other experiences to improve the UI.
3
Opus / Re: Opus and replay gain
Last post by doccolinni -
Quote from: Garf on
Maybe language lawyering over which RFC2119 definition "forbids" corresponds to exactly wasn't the best way to get to a constructive discussion.

Technical specs are intentionally written precisely in a "language lawyering" manner. If you're allergic to language lawyering, maybe you shouldn't engage with technical specs in the first place.

Quote from: Garf on
You're assuming here the decoder or player HAS these settings or even knows what ReplayGain is.

Not at all! If the player/decoder doesn't have these settings and doesn't know what ReplayGain is, then the player/decoder doesn't have these settings and doesn't know what ReplayGain is. That sucks I suppose, but it should not be up to the encoder/muxer to figure out how to make a player/decoder that sucks not suck, or do something it lacks the capability to do.

Quote from: Garf on
The foobar2000 behavior that you seem to object to is the one that gives the most desirable behavior with the dumbest players (while still working with better ones).

Incorrect/misleading. It gives what the foobar2000 devs have ascertained is the most desirable behavior with the dumbest players, while still working with the players that choose to break the spec by not necessarily applying the header output gain.

Quote from: Garf on
If you have a problem with that, that's on you, but don't be surprised that the developers continue to ignore you.

Ok...? I'm not sure what the purpose of this bit is, other than an attempt to be a snarky "gotcha".

Duly noted, I guess.

Quote from: Garf on
Going back through the past comments and how the spec evolved, you can actually see that R128_ALBUM_GAIN didn't exist initially...

Yes, I am very much aware of that, as well as the fact that that spec (the one that omits R128_ALBUM_GAIN) has been superseded and deprecated.

Quote from: Garf on
Quote
Furthermore, "use by default" out of context is misleading here, because it indirectly implies that the "other tools" can opt to not apply the header output gain.

It doesn't imply any such thing.

Yes it very much does, and that's not even this "language lawyering" you keep moaning about, but plain old elementary English. Something being said to be "use by default" is implied to be opt-out, i.e. the implication is that the decoders/players can choose to ignore the header output gain. And...

Quote from: Garf on
It describes what will happen if the user doesn't configure anything, or CANNOT configure anything, because the player doesn't really know about ReplayGain.

Yes, and if the player does know about ReplayGain/R128, then it still - according to the spec - must apply the header output gain, therefore the header output gain is not opt-out, therefore the header output gain is not "use by default".

Quote from: Garf on
Arguing that a player having *an option* to ignore parts of the spec is "breaking the spec" is simply not interesting.

I find it interesting and odd that you've elected to object with "not interesting" rather than "incorrect".

I mean, if you want, I can apologise that this has failed to pique your interest (even though your engagement seems to indicate the contrary). However, I fail to see the relevance...?

If this isn't interesting to you, well, then that's how it is I guess, but that's entirely immaterial to whether it is correct or incorrect.

Quote from: Garf on
Quote from: doccolinni on
Quote
       If a player chooses to apply any volume adjustment or gain
       modification, (such as the R128_TRACK_GAIN (see Section 5.2),) the
       adjustment MUST be applied in addition to this output gain in
       order to achieve playback at the normalized volume.

I do think you are misunderstanding this. See my last comment: this specifies that the gain tags are being applied ON TOP OF the output gain, and that the need to combine these operations is a hard requirement to get the right result. Hence the MUST for "in addition to...in order to achieve playback at the normalized volume". It's important that the implementer understands these need to stack or they'll get the wrong outcome when switching Track Gain to Album Gain and the reverse.

Yes, that indeed is what this
Quote
       or gain modification, (such as the R128_TRACK_GAIN (see Section 5.2),)
part of that sentence is about. I haven't misunderstood that at all.

What I have also perceived, understood, and taken into account, is this part of the sentence:
Quote
       any volume adjustment
Do let me know when you do so, as well.

Quote from: Garf on
Saying that a player that has a volume control is not spec compliant if it offers an option to ignore that tag is not just uninteresting, it's easily verified as wrong because the spec does use SHOULD and not MUST for applying the gain in the first place (see, I can RFC2119 language laywer too!).

Except that "SHOULD" only applies if the player/decoder doesn't do "any volume adjustment". If it does, then the "MUST" applies. This is elementary reading comprehension. If that's what qualifies as "language lawyering" to you... then I don't know what to say.

Quote from: Garf on
This very exact point is literally *spelled out* in the spec revision here: https://mailarchive.ietf.org/arch/msg/codec/zctRSJ84-Gd5G3XSUcNB-lAGSO0/

Same remark about the "S-H-O-U-L-D" as the above.
4
Support - (fb2k) / Re: m3u8 extension
Last post by merula -
No answer so far so where are the experts here...

I think if Foobar can CONVERT the file being played mostly called seglist or so nearly on the fly to mp3 tor example (60 minutes in about 2 minutes) it should be able to SAVE the file, too or not    
5
General - (fb2k) / Re: [Linux] Avoiding re-sampling of Foobar playback?
Last post by agentt -
pulseaudio occupies HW:0,0  so it disappears from foobar devices list. better to del pulse
i use wine alsa + wasapi push mode
in linux wasapi exclusive (EVENT) say output busy (Device in use)
i believe wasapi push is good for linux. coz alsa HW:0,0 is always exclusive  :)
7
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.
8
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.