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.
foobar2000, for all the reasons given above and below in my message.+1
foobar2000, for all seasons
Would anyone be kind enough to help me?
I'm trying to figure out the frequency/hz of this particular song for my brother, but I just don't know how. I followed a tutorial on another website about how to do it using audacity, but when I tried it, the frequency seemed to be 108 hz, so I think I must have been doing it wrong.
I'm sorry to post this again, because I saw some other topics about it on here, but I just couldn't understand them. I'm really sorry, I know absolutely nothing about music, but it's really important to my brother and I'd really like to help him.
This is the song: https://www.youtube.com/watch?v=Ju-WZtqEC-g
Can anyone explain to me, as simply as possible, how I can find out what frequency it is?
Thank you so much for reading.
4: Compile-time options that allow configuration of what is on or off on default? Maybe an idea in itself.
But once you allow for that, consider also an option --defaultconfig that switches off all compile-time configurations.
And still there can be a new option for --enforce-minimum-bitrate or whatever you call it, and a negative option.
That's some weird logic.You mentioned 'responsible disclosure'. If I distribute a bunch of files that might trigger security issues in various programs, that's hardly responsible disclosure, is it?
Most Windows software that I have, have no problem with this file, including Winamp native and old with the plugin, SMPlayer/MPV, Foobar old and new, XMPlay, AIMP, DirectShow/DC-Bass, iZotope RX5, OpenMPT, MPC-HC/old, MPC-HC/LAV, Reaper 6, SoX.Then it is less of a problem than I feared.
Well such files should go into the testbenchYes, seems like a good fit.
That points towards further restrictions to today's "Subset". More layers of strictness/laxness wouldn't be optimal, but if the mountain won't come to Muhammad ...The reason I suggested it could be linked to using --lax is because this problem makes streaming difficult. Seeking is something that players must fix, but I think getting players to not stop playing because a buffer runs thin on a bitrate of 1.4kbit/s (that means a single TCP/IP packet of 1500 byte can contain more than 8 seconds of silence) is way more difficult. The goal of the FLAC subset is twofold: to enable streaming and to lower requirements on hardware implementations. This is clearly something that has to do with enabling streaming.
I see a couple of options
- Link it to the usage of --lax, because it is streaming related. When someone uses --lax, the encoder no longer ensures no block with only constant subframes are created
- Link it to a compression level. This can technically be done without changing the API/ABI, but this is not nice to users as they cannot choose for themselves to enable or disable it
- Create a new option in FLAC and new functions in libFLAC API/ABI. While not really a problem, I prefer not touching the API/ABI when possible. It will also require modifying streaming server applications using libFLAC
- Create a compile-time option, so a special libFLAC with this enabled can be distributed for use with FLAC streaming server applications. This can only be used for such applications where FLAC is dynamically linked (in other words, libFLAC is a dll or so)
The last option is probably the cleanest, and more or less what is happening right now as I asked a few people through github to test this patch for me.