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
1
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Porcus -
compilation flags which impact on quality you find difficult to assess?
Nothing says they are any wrong. Nothing says that "no compilation flags" is any more correct than "these compilation flags".

16 bits is enough if done properly.
There is a common misconception that a floating-point number is "inaccurate". A floating-point number is a sequence of 32 given bits, but 32-bit floating-point numbers are adequate for when that is accurate enough - whether that is because the actual resolution is less and they are exact, or whether it means you have to perform an "acceptable" roundoff before fitting it into the 32 bits. (Like, try 1/3.) 
Floating-point arithmetic allow operations that might require round-offs for the result to fit a 32-bit number. Maybe this direction, maybe that direction - it is adequate when it is good enough.
And if it is good enough, than this CPU's platform's roundoff is good enough, and so is that platform's roundoff - even if the end-results are rounded off to different 32-bit floating-point numbers ...

... which, in themselves, are approximations of something that in this application is an approximation of your original signal.
Even if you dropped the latter "an approximation of", it would be good enough for audio processing (DAWs can do well with 32-bit floating-point!), and now it is even used to make a lossy file, which is a "manthematically very rough but audibly good enough" approximation to the original signal.

If you encode it on your computer and play it back on your phone, the different CPUs might differ in roundoffs in precisely the same way.


And the impact is much smaller than the lossiness of the encoder - unless a particular implementation is stupid, and if so is the case, you don't even know that "your" compiler flag set is not the stupid one.
3
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
We have an ancient code here that needs to be dusted off first, whereas you are in a hurry to attach wings to it so that it flies even faster, although it is already faster than LAME anyway.

The changes done so far are exactly that: Dusting off the codebase by fixing things that are clearly bugs (uninitialized variables, wrong buffer initialization). Such bugs can very much lead to unexpected crashes or distortions.

Nobody here is messing with the core algorithms. The compiler flag explorations are in some way a means to check that the codebase behaves reliably and predictably across platforms. The default settings always will tend towards the safe and reliable, but its good to know that even aggressive compiler optimization don't outright explode.
6
Support - (fb2k) / Re: foobar2000 for Mac: bugs & wishes
Last post by Guildencrantz -
Great features in today’s preview version, but:

Buttons in the redesigned properties window are slightly cut off at the top.

Saving Accurate Rip logs is fantastic, though I have two minor gripes:
1) it suggests .txt extention instead of .log
2) it uses Windows CRLF instead of Unix LF.
7
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Wombat -
Dear developers, I listen to your every word with great attention and I am taken aback. Why do you use compilation flags which impact on quality you find difficult to assess? Since when did chasing fractions of seconds become more important than quality? We have an ancient code here that needs to be dusted off first, whereas you are in a hurry to attach wings to it so that it flies even faster, although it is already faster than LAME anyway. If there is even the slightest chance that the quality could deteriorate in at least one frame by at least a bit, such compilation flag should be omitted. Aren't there other projects that can be turned into a proving ground? Helix MP3 encoder should be approached with care, in the spirit of restoration, as the title of the topic suggests.
It isn't that easy. @maikmerten already explained that compilers of different origin may change the output more as setting flags inside one and the same enviroment.
We need golden eared peoplle like you to find out if there is a way to tell them apart.
8
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -
Dear developers, I listen to your every word with great attention and I am taken aback. Why do you use compilation flags which impact on quality you find difficult to assess? Since when did chasing fractions of seconds become more important than quality? We have an ancient code here that needs to be dusted off first, whereas you are in a hurry to attach wings to it so that it flies even faster, although it is already faster than LAME anyway. If there is even the slightest chance that the quality could deteriorate in at least one frame by at least a bit, such compilation flag should be omitted. Aren't there other projects that can be turned into a proving ground? Helix MP3 encoder should be approached with care, in the spirit of restoration, as the title of the topic suggests.

9
3rd Party Plugins - (fb2k) / Re: UPnP: How does the Media Library Tree work?
Last post by SimBun -
For example, what's the difference between object.container.album.musicAlbum and object.container.genre.musicGenre. Obviously, one has to do with Albums and the other has to do with Genres, but I can't tell what they're specific functions are.  Also, which object.container do I use for single tracks?  I saw something about object.item, is that a thing?

Before you dig in too deep, are you sure you want to start using a component that hasn't been updated in 9 years and only works with foobar x86 (and only runs on Windows)?

From the UPnP Content Directory specification:
Quote
A class is used to assign a type to an object. It also identifies the minimum required set of properties that shall be included in the object’s metadata and the allowed properties that may be included. Classes are organized in a hierarchy with certain classes being derived from others as in a typical object-oriented system.

If you want to create other indexes you should be able to use 'object.container'. e.g.
Code: [Select]
    <spec type="object.container">%releasetype%</spec>
    <spec type="object.container.album.musicAlbum">%album%</spec>

Music tracks are <upnp:class>object.item.audioItem.musicTrack</upnp:class> but the component will populate those for you as part of the musicAlbum class definition.
10
Opus / Re: Opus v1.5.1
Last post by Marsu42 -
LACE/NoLACE is post-processor that works after SILK decoder and can be optionally enabled at decode time. In other words, there's no difference on the encoded bitstream

Thanks for the explanation - I have to admit that after reading the 1.5 release news. I didn't understand that there's no encoder side change at all.  I hope apps will enable noLACE decoding - alas, it's probably hard to tell, esp. because there seems to be little difference at moderate bitates (I'm usually encoding podcasts at 24 kbps).

Another question: The release notes state "LACE and NoLACE are currently only applied when the frame size is 20 ms." (https://opus-codec.org/demo/opus-1.5/) - is this just for the time being at this will expand to other frame sizes? Until now, I've used 60 ms for podcast offline encoding to save a little file size...