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
2
General Audio / Re: How do you test SACD audio dynamic range?
Last post by wojak -
I have the 2024 Steely Dan - Aja new release from Acoustic Sounds Analogue Productions.

I can get the DSF files from disk, but I'm facing that the audio level can be easily manipulated by changing the volume [db] 0 - +6.
Can you get an honest dynamic range from SACD? 🤔

Good old and much hated DRmeter plugin for foobar will measure it and even write the DR to tag. But it only works in 32bit version of Foobar.
Replaygains also works - from that you can get True Peak, LUFS and PLR.
It works on SACDiso so probably on DSF and DFF too.
4
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
These changes are only style- and safety-changes.

The memset for spd_cnt1Short shouldn't change runtime-behavior at all, as both spd_cnt1Short and spd_cnt have the same size, thus memset doing the same. This is only fixing a copy&paste oversight, and I fixed this to avoid confusion.

The memset for w_spdShort is more serious, as w_spd is a *bigger* buffer than w_spdShort and thus the memset would write zeroes beyond the boundaries of the w_spdShort-buffer. However, if the encoder doesn't crash during initialization, no effect otherwise is necessarily expected.

I checked before and after the changes, and the MP3 output remained identical.

As for providing fresh builds for whatever current git-state: Well, if several people keep their build-environment fired up, even if the changes are minimal, it is beneficial to know that no breaking changes were introduced by accident. I can only test on Linux and with whatever compiler version I have installed, so having another set of compiles available can be useful to gauge whether some recent work broke things.
7
Listening Tests / Re: Great killer sample, easy to ABX on most codecs
Last post by Kraeved -
Lame 3995o vbr -q1 cannot be better than any 320cbr. Helix is old, good yes but still mp3.
Just in case for less informed users among us: it's not -q1, but -Q1, a tweaked approach implemented by @halb27.

Actually, I agree with @maikmerten, who said: “Your LAME 3.995o encode did overall a better job, certainly better than LAME 3.100 for this sample. However, as one can see in the spectrogram, it somewhat avoided most of the sbf21 trouble by effectively lowpassing the high frequency band [using transition band 17960 Hz - 18494 Hz] and thus getting rid of the excessive energy there, which might be the best tradeoff in this case”. Helix without -HF2 used an even lower 16536 Hz limit and also sounds fine (with enough hiss, but without metallic fluctuations and ultrasonic bloat).

Input.


Output. lame3995o -Q1


Output. hmp3 -V150
8
3rd Party Plugins - (fb2k) / UPnP: How does the Media Library Tree work?
Last post by chrisdukes -
I specifically referring to the foo_upnp_ml_tree.xml from the UPnP/DLNA Renderer, Server, Control Point component.

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?

Is there any documentation out there?

Thanks for any help!
9
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -
Do you bother to check the github before you make these comments? Nothing has changed quality-wise.


What is it? @john33, are you ready to put your reputation on the line and walk out the window if this change does affect the quality to speak about it so confidently? Or will we let the author of the edit have his say? Helix's legacy is already fraught with obscure code and mysterious options such as -TX and -SBT, so it is not surprising there is increased attention to changes, especially unannounced.
10
Listening Tests / Re: Great killer sample, easy to ABX on most codecs
Last post by bryant -
> In this case ,32 khz makes it worse as the noise has nowhere to go but down the spectrum.  In contrast, 48khz works better.

Do you mean, it subjectively sounds better at the same bitrate? (I don't think it *has* to always be worse in similar cases. All of the noise has to go to the audible range indeed, but the noise floor can be lower because there are more bits per sample available. It's probably very difficult to truly predict how it'll go in general.)

> When this was converted back to 16-bit most of that noise should have been filtered out.

Why/how? I don't think this is how it works. Converting an integer from less bits to more bits is lossless (perfectly reversible). Do you mean there is some extra step that you'd expect to always happen in tandem with that?
There are two different scenarios to consider. The first is that we want to preserve this pathological audio, and the other is we want to salvage it.

Since the vast majority of the energy in the sample is at frequencies that some people can hear and some can’t, this is going to sound very different to different people. But if the goal is to preserve that loud hiss, say for some nostalgia, then it’s sort of hit or miss as to what a lossy codec is going to do (as we’ve seen) because there’s all kind of ways that could fail, either in analysis or processing.

The recommendation is generally to not transcode from one lossy format to another (and converting to 8-bit PCM is a very lossy operation), so my advice would be to play it safe and accept the great lossless compression that you can get (because of the 8 bits). Keep in mind that the pathological amounts of hiss may very well create other distortions in your playback system, from resampling engines to DACs to transducers, but I assume that’s all acceptable and that any ABX testing you do is suspect.

On the other hand, we know what the artist intended this to sound like (from YouTube and Spotify) and it does not have pathological hiss. That was an artifact of converting to 8-bit PCM (for a game audio perhaps?) and so it seems reasonable to me to try to remove that to make everything more palatable for lossy encoders, and that’s very easy to do. The useful audio here goes up to about 14 kHz, so I used my ART program with a gentle 48-tap sinc lowpass at 15 kHz and got the attached file. You can see the lowpass profile here:



That still has some audible hiss (like maybe from a cassette or FM recording), but should be an easy encode because it looks like real audio.

There also seems to be a misconception here. Resampling audio from 44.1 kHz to 32 kHz does not require the noise “to go somewhere else”. Proper downsampling involves an anti-aliasing lowpass filter that removes frequencies that are no longer valid at the new sampling rate (i.e., >= Fs/2), so when I use my tool again to convert this (using default settings) to 32 kHz it’s fine and the crazy hiss is gone and it should be easy to encode. If some other program is doing something else and making this worse to encode, it’s not being used as intended or buggy.

And I’m not suggesting that increasing the bitdepth of integer samples requires any filtering because it is, as you say, lossless. But in this particular case there is a lot of dither noise that is there only because of the reduced bitdepth, so it makes sense to remove it if you can do so without removing too much useful audio information.

And, by the way, if all this wasn't true then DSD wouldn't work because it's completely based on downsampling 1-bit audio and removing the dither noise.