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.
and folks there talk constantly of the noise problem in desktops.
TRUE - You can have noise (hum, hiss or whine in the background). But if you had audible noise you'd know it.
I had a soundcard once that had noise when the hard drive was accessed (or it was worse when the drive was accessed).
That's about the only thing to worry about. Frequency response and distortion are almost always better than human hearing.
Or, sometimes a headphone load (which will have varying impedance over the frequency range) can cause related frequency response variations.
Note that USB power tends to be noisy and occasionally noise can get into the analog-side of a USB powered DAC through the power. (Usually it's a "whine".) A DAC with it's own separate power supply will avoid that possibility.
Last post by Porcus -
Looks like the explanation is here: https://www.jwhitham.org/2023/09/system-shock-soundtrack-gapless.html Correct Xing/LAME tag that fb2k fails to read because the next frame is faulty. Since bad mp3s are all over the world, leaving it up to the decoders/players to work around, I guess fb2k could use a fix that gets the Xing/LAME header correct? Quoting:
Quote
The System Shock MP3 files are 320kbit MP3s, so each frame is either 1044 or 1045 bytes in size. Stepping through the code with GDB, I realised that the problem is not the Xing/LAME tag itself, but rather the frame after it. mpg123 and Foobar both expect the next MP3 frame to start at the correct place, exactly 1044 or 1045 bytes after the first one. But it's not present: instead, that part of the file is zero. mpg123 and Foobar both assume that the Xing/LAME tag is invalid and ignore it.
As for that TEST.wav file, I can replicate. I got winLAME to create bit-exactly the same file as yours whether or not I choose the gapless option (adding --nogap). MediaInfo reports it as one minute. Audiotester says "(LOST SYNC @ 0m 00s)" ffmpeg: "Skipping 680 bytes of junk at 771."
Last post by renderMan -
Also, when I'm trying to add a component it's giving me the error "Cannot access configuration folder: Access denied" with my portable exe.
drop table if exists albumSummary; create table albumSummary as select album, [album artist], date, round(sum(rating*length_seconds)/sum(length_seconds), 2) as albumrating from Playlist where playlist_index = active_playlist() group by 1, 2, 3;
update PlaylistUpdatable as a set albumrating = b.albumrating from albumSummary as b where playlist_index = active_playlist() and a.album = b.album and a.[album artist] = b.[album artist] and a.date = b.date; drop table if exists albumSummary;
Last post by A_Man_Eating_Duck -
I just gave this a test using the standalone winLAME 2021 release 1 and Foobar2000 v2.1 32bit (2023-09-22). I also tested a portable install of foobar2000 v1.6.16 with the same results.
I created a 1 minute single channel wave file of silence in audacity and used winLAME to encode it using the HQ: hifi setting (-V2 --vbr-new). The resulting mp3 is reported in Foobar2000 as being 128kbps and the length 0:14.956.
WARNING: "C:\Music\TEST.mp3" (offset 0x2e4): MPEG stream error, resynchronized successfully WARNING: "C:\Music\TEST.mp3": Wrong number of MPEG frames specified in Xing header (2298 instead of 2301) WARNING: "C:\Music\TEST.mp3": Wrong number of MPEG data bytes specified in Xing header (239409 instead of 240034)
Last post by wheelie -
Windows 10 and foobar2000 v2.0 [x64] standalone here.
Recently I converted some flac files to mp3 with WinLAME. I noticed that fb2k showed the duration time of mp3 incorrectly. I thought it was WinLAME issue and informed the dev. I provided a flac and an mp3 file. After running some test the results were suggesting that there might be a bug in fb2k:
Quote: "I examined the Xing VBR tags that the LAME-produced and foobar2000-fixed files provide, and they are nearly identical and within the Xing VBR tag specifications. I also checked the files using ffprobe from FFmpeg and they report a correct playback time. So I suppose there might be an error in foobar2000."
About the mentioned "foobar2000-fixed" thingie, quote: "VLC can correctly show duration of VBR files. I guess they scan the whole mp3 file. foobar2000 doesn't do this, but offers a menu item "right-click > Utilities > Fix VBR MP3 header...", which fixes the duration for foobar2000. It does this by adding a Xing INFO tag that the unmodified mp3 file is missing, which is strange, since it should have been written by LAME..."
