Hi Uli.
Yes I know. I can also use Foobar. I'd like to use Linux though.
What I do is following:
1. Apply replay gain according to 89db reference (-14db relative to full scale)
with metaflac
2. Apply a system specific correction value to the album gain tag with
puddletag
3. Squeezbox Server adds that value to the actual volume setting prior
to processing.
The plan is to handle 1.+2. with puddletag in the future.
I can highly recommend puddletag as tag tool. It's just the best I came across.
Cheers
Hi guys.
In OSX land there are apps (Pure Audio - The OSX Reference Player and Audirvana) which offer a so called integer mode.
The stock OSX was and still is feeding the DAC drivers with floats.
These rather new audiophile minded apps avoid that float/integer conversion now on driver lever. They feed integers to the driver.
The driver needs to accept integers of course.
People claim that this is effect is audible.
Does anybody know how it's done in Linux land?
Cheers
In OSX land there are apps (Pure Audio - The OSX Reference Player and Audirvana) which offer a so called integer mode.
The stock OSX was and still is feeding the DAC drivers with floats.
These rather new audiophile minded apps avoid that float/integer conversion now on driver lever. They feed integers to the driver.
The driver needs to accept integers of course.
People claim that this is effect is audible.
Does anybody know how it's done in Linux land?
Cheers
Last edited:
Which card supported by alsa accepts float samples? I do not know of any, apart of perhaps X-fi. Maybe there are closed-source drivers in OSX where the card/driver manufacturer chose to use both int and float samples for communication between the userspace and driver and Pure Music goes for the int format only now. Unfortunately we cannot check the source code and have to rely on often vague description by the author.
I do not see this feature anyhow relevant to alsa.
Last edited:
Or maybe I understand the wording differently and the author means the player does not do any floating point operations. Though I have no idea why for certain DACs only.
In any case bit-perfect chain in alsa does no FP operations. The sample rate converters do, as well as perhaps the softvol plugin.
For up to 24 bits the conversion between int and float is bit perfect as the mantisa of float32 has 24 bits.
Why should several int instructions on CPU sound better than a single float instruction on the same CPU?
In any case bit-perfect chain in alsa does no FP operations. The sample rate converters do, as well as perhaps the softvol plugin.
For up to 24 bits the conversion between int and float is bit perfect as the mantisa of float32 has 24 bits.
Why should several int instructions on CPU sound better than a single float instruction on the same CPU?
No, as far as I understood it is about feeding the driver with integers instead of floats. Not all drivers were supporting it , since OSX requires floats.
Todays 32 bit DACs do push the limits. Float/integer conversions do need to be discussed in this context I guess.
The reason behind all that is to avoid extra processing further downstream.
They now follow pretty much the same philosopy that I'm running since years.
Cheers
OK, I do not know what part of OSX specifically requires floats. Alsa drivers almost exclusively expect integers.
Well, they accept 32bit samples as it is a cheaper and more universal format to handle. Effectively they do not exceed 19-20bit S/N as it is down to physical properties of chips. Since internally they are one-bit DACs anyways, it is just about the digital control circuits. No advantage for their analog performance over 24bit-only DACs.
IMO the driver should accept only the sample formats the hardware actually supports. Conversion from any intermediate or source formats is job of user space layers. Standardizing on float32 would be unexpected. But who knows how it actually works in OS-X. I don't
Hi there.
A sidenote to the float integer conversion discussion.
You might find int-float-int-its-jungle-out-there.html
interesting.
It seems that it is not that easy to say if an application or library
delivers bit transparent data if it messes around with the float/integer
conversion.
A sidenote to the float integer conversion discussion.
You might find int-float-int-its-jungle-out-there.html
interesting.
It seems that it is not that easy to say if an application or library
delivers bit transparent data if it messes around with the float/integer
conversion.
Hello,
Try libebur128. http://www-public.tu-bs.de:8080/~y0035293/libebur128.html
It implements the EBU R-128 loudness recommendations. Foobar2000 has switched to R-128 recently.
The r128-scanner command included in the packet can tag directories recursively. No problems with 96/24 in my tests also.
Cheers,
Roberto
Great stuff Roberto. Thx a lot. That seems to be exactly what I was looking for.
I didn't know about those EBU R-128 recommendations, since I never considered using replay-gain for a long time.
Just recently I figured that the Squeezebox-server just adds the gain to the normal volume settings.
I tried it and was very happy with the result. I do consider it extremely annyoing to adjust the volume for each
and every album.
I found a nice article about those EBU recommendasions. An interesting read I think.
I hope that one day the mastering studios comply to such a standard.
And a big "thank you" to the folks fighting the Loudness-War and not giving up on it for quite some time.
Cheers
Last edited:
Hi folks.
One more remark to the float/integer thing.
I just learned that e.g. even ecasound (my prefered engine) was not transparent ( Kai Vehmanen - the guy in charge - called it asymmetric) prior to 2.8.0. .
2.8.0/2.8.1. is not even available in the Ubuntu repos btw.
Those folks running e.g. MPD should get that issue highlighted with the MPD folks. Just to make sure that they run symmetric.
Cheers
One more remark to the float/integer thing.
I just learned that e.g. even ecasound (my prefered engine) was not transparent ( Kai Vehmanen - the guy in charge - called it asymmetric) prior to 2.8.0. .
2.8.0/2.8.1. is not even available in the Ubuntu repos btw.
Those folks running e.g. MPD should get that issue highlighted with the MPD folks. Just to make sure that they run symmetric.
Cheers
@Roberto
I just downloaded the 32bitSSE package which comes with a binary.
Then installed the dependecies
And then I ran it:
Works great incl. tagging and hirez material.
I've just written a script that runs libebur128
over my collection.
Thx again for the hint.
Cheers
I just downloaded the 32bitSSE package which comes with a binary.
Then installed the dependecies
Code:
sudo apt-get install ffmpeg libmpcdec6 libmpg123-0 libsndfile1 libtagc0And then I ran it:
Code:
cd /usr/src/libebur128-0.4.0-Linux-sse2 ; ./r128-scanner -t album <dir>Works great incl. tagging and hirez material.
I've just written a script that runs libebur128
over my collection.
Thx again for the hint.
Cheers
I'm glad you liked it.
And thanks for the debian-ubuntu tips, I failed to install it in my ubuntu machine. The music server is a gentoo box, though. Those in that case can find the package in the pro-audio overlay, it is not in the main distro yet.
It is great stuff indeed. I particularly like the well tested algorithm in use, that make me feel confident about the results. You can find it detailed here:
http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-2-201103-I!!PDF-E.pdf
Yeah, but is everything really well-designed under accuracy aspects?
The K-filter is designed as a 2-stage filter, a first stage shelving filter and a 2nd stage highpass filter (RLB-weighting curve). The coefficients are given for a samplerate of 48 kHz and it is the task of the programmers to carry out the proper filters for other samplerates.
It would be perfect to define the filters as biquad filters with the given specs about frequency, Q and gain. Then it is easy to compute the filter coefficients for all samplerates. But now the coefficients are given only for 48 kHz. So if you assume now the filters as biquad filters you can try to solve the equations to get f0, Q and gain. This is possible for one of the filters. For the other filter you get just an approximate solution but no accurate one! So the K-filters for other samplerates (calculated from the approximate values for f0, Q and gain) will be more or less identical between different programs and give different results.
Uli
Great point, it is extrange the way the weighting filter is defined. Given the nature of the estimation, I think the very small variations in results that have to be expected are not important, but assuring complete repeatability between different programs would have been better.
Test material exist to check implementations (EBU TECHNICAL - Loudness) but it should be resampled (it is all 48 khz) for each case.
There is an unofficial paper for the parameter estimation: http://www-public.tu-bs.de:8080/~y0035293/ITU-R-BS.1770-1-filters.pdf
libebur128 is using exactly the estimated parameters. So far ok. It just should be noted that calculating the coefficients from the estimated parameters differ from the coefficients in the specs.
So I'm wondering why the specs define the coefficients with such precision. You can use them for 48 kHz but not for other samplerates. Or you can use the estimated parameters (like libebur128) but then you do not precisely follow the specs at least @ 48 kHz
Uli
libebur128 is using exactly the estimated parameters. So far ok. It just should be noted that calculating the coefficients from the estimated parameters differ from the coefficients in the specs.
So I'm wondering why the specs define the coefficients with such precision. You can use them for 48 kHz but not for other samplerates. Or you can use the estimated parameters (like libebur128) but then you do not precisely follow the specs at least @ 48 kHz
Uli
Linux and Acourate, a perfect pair!
Hi there,
I am diying PC-audio since several years and began with Windows XP and Tact 2.0, followed by Bidule from ploque and DRC on OSX.
The latest version was Winows7 64bit on an overclocked Intel dual core system. The crossovers were built with Sonoris Mastering EQ and I used still DRC on SIR2 as convolver. I was really satisfied with the sound quality. Especially when I changed the soundcard from an ESI ESP1010e to the wonderful X-Meridian 2G from Auzentech with a change of the OPAmps.
Then I read about the qualities of Acourate and tried it out with a stereo correction file in this constellation. I was flashed from the effect on the sound and could not listen to music without this room correction anymore.
But I wanted to use the phase linear crossovers of acourate as a try and wanted to work with a Linux system.
After some days of trying and with "a little help from my friends", I got to the GNU/Parsix 64bit system, which ist more comfortable than the text-based distributions without having a big overload of unnessecary stuff like Ubuntu and others.
Now I am running the Acourate crossovers with integrated room and measuring-microfone correction in brutefir, which is giving the signal via jack to the soundcard. The player is aqualung, which is the only one I found to be able to play uncompressed wav-files.
I am overwhelmed by the sound, Never thought, that this could be possible.
Hi there,
I am diying PC-audio since several years and began with Windows XP and Tact 2.0, followed by Bidule from ploque and DRC on OSX.
The latest version was Winows7 64bit on an overclocked Intel dual core system. The crossovers were built with Sonoris Mastering EQ and I used still DRC on SIR2 as convolver. I was really satisfied with the sound quality. Especially when I changed the soundcard from an ESI ESP1010e to the wonderful X-Meridian 2G from Auzentech with a change of the OPAmps.
Then I read about the qualities of Acourate and tried it out with a stereo correction file in this constellation. I was flashed from the effect on the sound and could not listen to music without this room correction anymore.
But I wanted to use the phase linear crossovers of acourate as a try and wanted to work with a Linux system.
After some days of trying and with "a little help from my friends", I got to the GNU/Parsix 64bit system, which ist more comfortable than the text-based distributions without having a big overload of unnessecary stuff like Ubuntu and others.
Now I am running the Acourate crossovers with integrated room and measuring-microfone correction in brutefir, which is giving the signal via jack to the soundcard. The player is aqualung, which is the only one I found to be able to play uncompressed wav-files.
I am overwhelmed by the sound, Never thought, that this could be possible.
beets: the music geek’s media organizer
A very interesting new entry in Debian "Sid":
beets: the music geek's media organizer
beets: the music geek?s media organizer — beets v1.0b10 documentation
A very interesting new entry in Debian "Sid":
beets: the music geek's media organizer
beets: the music geek?s media organizer — beets v1.0b10 documentation
I'm using dbpoweramp which comes with the so called Perfect Meta feature.
Musicbrainz is just one out of several databases used to assemble the "perfect"
tags.
My opinion: I havn't seen any database (accessible to normal users) that's generating consistent tags.
The DPB Perfect Meta thing I consider useless.
I doubt that beets can do it any better.
Musicbrainz is just one out of several databases used to assemble the "perfect"
tags.
My opinion: I havn't seen any database (accessible to normal users) that's generating consistent tags.
The DPB Perfect Meta thing I consider useless.
I doubt that beets can do it any better.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.