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.
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.
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.
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.
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.
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.
QuoteFurthermore, "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...
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".
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.
QuoteIf 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
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:
any volume adjustmentDo let me know when you do so, as well.
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.
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.
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
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
Should be a pinned ...
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.
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.
An 64-bit decoder library for the SDK.Thank you! I'll include it with the next release of Mp3tag.
Nothing to do with .ogg or Vorbis.
Is this good enough for you? Both in original AMR format and also MP3 if you need it for compatibility.
See you tomorrow.