Skip to main content


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
3rd Party Plugins - (fb2k) / Re: foo_uie_lyrics3
Last post by marc2k3 -
If it looks in the playing file's folder by default, I guess Lyrics\%filename% would do but I don't use the component.

%filename% discards the .mp3/.flac - you might have to append .lrc or whatever the file format is.
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.
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.)