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.
Last post by Air KEN -
v2.11.0.0-alpha1, 2024-05-11 Unable to install. This message is appearing.
> Information > Failed to load DLL: foo_midi.dll > Reason: This component is missing a required dependency, or was made for different version of foobar2000.
Last post by Case -
Sorry about the crash bug, @Porcus. Copy/paste bug. Before printing album DR number the code tried to check if album LRA result was valid. Since you had LRA disabled in the settings it tried to read from unallocated null pointer. Fixed version with the changes made per Defender's suggestions uploaded to the usual location: https://foobar.hyv.fi/?view=foo_truepeak.
Last post by Case -
There should be no offset difference. But most audio editors can't take the padding information in LAME tag into account to get the offsets and file lengths right. You can use at least current version of ffmpeg, lame or foobar2000 to decode MP3s correctly and verify the problem that way. With foobar2000 you can also use its Binary Comparator feature, it will automatically detect offset error in compared files and report it. If there's an offset even with known good decoder, can you share what parameters you used to encode and what kind of source file? It's possible some exotic combination has gone untested and is bugged.
There is a gap between the Left (flipped) and Right channels in bar mode (also in spectrogram mode but I don't use it). Would it be possible in a next relase to be able to ajust this gap to null ? [attach type=image]30627[/attach]
Yes, an alignment option (left, right, center) is on the To Do list for the next version.
Last post by jaro1 -
Rough estimate without specific numbers.. this binary (GCC14.1) achieves on my particular Intel CPU 8.gen for encoding the wav file (24/44, length 1:20 hour) same speed as both Joshua's latest dev binaries (GCC13.2, Clang). The binary from the post #377 (from Wombat, GCC13.2) is with encoding of this particular file about 1/3 slower (ca. 185x vs ca. 122x).
At this point, I would like to thank Maikmerten, Case and the other programmers who contributed with their builds in this thread to the resurrection of this mp3 encoder, you guys are awesome!!
One note... I know that there have been various modifications and changes leading up to the current git version, so it's possible that this has been discussed in some part of this thread and is therefore known.. i didn't proven, if this "behavior" is consistent with every file, but converting the file with hmp3 causes an offset of approx. 24 samples at the beginning of given mp3 file while maintaining the overall length. In comparison, Flac and Lame encoders in their latest versions are completely identical to the original wav file. In case I'm not "kicking the opened door" here, I'd ask for confirmation of this.. I'll just add that I noticed it accidentally when manipulating the file in the wav editor. Limiting the parameters for the encoder has no effect on this.
Last post by tiptoetan -
i use "media library search" feature heavily. what i greatly miss there is to have a search history to be able to repeat a previous search. i am thinking of getting into the whole plugin development thing to at least create something like that myself. btw thanks everybody for an indispensable program.
@Defender - Here's a new build that should address your concerns. I didn't replace the old and stable build yet because I may still do some tweaking. I may even re-use the same version number for further experiments. Download: https://foobar.hyv.fi/foo_truepeak_0.6.4.fb2k-component
I'm starting to wonder if the name of this component should be renamed to something like Loudness scanner. I could give separate scanners own context menu entries, but the extra stuff has accumulated in because people wanted to scan multiple things at one go. I'll probably add the extra commands anyway, hidden by default, especially if Defender likes the new idea of moving the context commands into a separate group of their own instead of camping in the ReplayGain menu.
Functionality of 0.6.4 is excellent.
I do not have any input about renaming the component or not a as long as functionality stays like this please.
BTW. I don't understand requests for partially scanning when some information (like rg) is already known. You do one scan (I assume) to accumulate the various truepeak, clipping, lra and dr stuff. So how much time would be won if for instance the DR part would be excluded? IMO it's quite efficient to do them all when I request a scan.