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
5
General Audio / Re: deduplicate files -> and create symlinks / softlinks instead
Last post by Porcus -
The reason I have "wishlisted" that feature is not deduplication though - it is to expand padding to take up all the space that the file is anyway going to use on disk. Bigger padding and fewer full rewrites, costlessly.
But when you do have deduplication, aligning the start of the audio makes the most sense because it ensures the audio will never share a block with metadata. ZFS won't waste an entire recordsize block for the end of the file as long as you enable some form of compression.
If you have an "ideal" file system that can sneak in more blocks "midway" in a file - and a tagger that can do it and thus "maintain deduplication" - then that is the way, especially if you don't know the audio length upon encoding. (If you knew, you might as well write an encoder that starts at the end.)

But if you don't have that luxury, then starting audio with z bytes zeroes and a bytes audio shouldn't be much different to the file system than ending it with a bytes audio and z bytes zeroes. You can always keep those z bytes if you want, but you have the additional advantage of writing tag data into it if and when you are in a situation where doing so saves a full tag rewrite. You simply have z bytes more padding, and that is not a downside.

Instead of course, you can use audio formats with (APEv2) tags at the end. Disadvantages and advantages to either solution.
6
MP3 / Re: Any particular "lesser known" reason to keep ID3v1 tags?
Last post by Porcus -
The combination of buggy applications might make a case for one or the other - and here it is against end tags, even the more sane APEv2.
Especially when one of those is a fairly common one: Looking at you, ffmpeg.

I have a bunch of MP3 files which "aren't terminated properly" - it seems some applications keep converting to the end of the source file, and then stopping, leaving the last MPEG frame incomplete? Anyway, those show up as "truncated" when using zealous MP3 validation software.

And then ffmpeg keeps on reading. Into the tags section, if there are any such at the end.
Sure one may - sometimes - appreciate that an application that tries to salvage out as much audio as possible from corrupted files, but for standard playback you would rather have it mute than spit noise at you.

Anyway, until ffmpeg fixes this, then its audio hash functionality is broken. The foo_audiomd5 component uses ffmpeg, and if the file has this kind of truncation at the end and you change end-tags - then the "audio checksum" will come out wrong.
It seems one avoids it by never changing end-tags. Which in turn, is most easy to do if you don't use end-tags at all.

(I was once musing about dropping ID3 altogether and going for APEv2. Won't happen. ID3v2.3 has its shortcomings, but at least it is supported. And since I intended using foo_audiomd5 for fingerprinting lossies ... writing that to APEv2 on those truncated files, will immediately invalidate it.)
8
General - (fb2k) / Re: Foobar2000 Wrapped
Last post by paregistrase -
I mean that the repot take a month forward. For example In the 2024 it gives values to march, for example it says special day March 17 and the artist graphs have an offset month too.
10
foobar2000 mobile / Re: [skinning] replay gain conditional evaluation
Last post by Daiki -
As far as I know, it is impossible at this moment.
This is because
whether or not the replaygain information is tagged to a track and whether or not the user is using the replaygain function when playing the track
are different things.

Currently, there is no way to get the status of replaygain mode.

It would be nice to be able to refer to the various internal statuses as boolean values regarding playback within if statements, as you have shown in your code,
and also directly as variables within the [label] element, I think.
If this feature is implemented, my issue will also be solved.

I guess that perhaps the skinning of foobar2000 for mobile utilizes unique scripts.
So when implementing new variables and syntax, I think it is necessary to scratch functions for parsing user-defined skin files. This is a painstaking process.

Ideally I would like to be able to design the appearance as flexibly as HTML, Javascript, and CSS,
but that would involve redesigning the application from the ground up, which would be difficult...