I have a question about plexamp and its use of replaygain for a preamp gain of +4 on plexamp. First, is having any in app gain altering the music and keeping it from being bit perfect, and if so, should I keep it at 0, because the default of the preamp gain in app using replaygain is +4…tldr does the in app preamp gain setting keep music from being bit perfect or is it doing something else that I don’t understand?
Bitperfect can only be achieved if the audio stream is not altered in any way. That includes changing the volume.
So no: using replay gain prevents bit perfection – with or without preamp gain.
However: “bitperfect” is highly overrated. If you use a high enough precision to perform the multiplication (which is what is happening when digitally changing the volume), then the result is still very, very high quality. Plexamp uses 32bit floating point precision to do that.
Just to put it into perspective: “bitperfect” was coined by Bob Katz when talking about mastering for CD. (which uses 44.1 kHz and 16 bit)
And that was decades ago.
Nowaday’s playback chains are usually using 24 bit precision. So the whole issue of bitperfect signal chain is much less important. The additional 8 bit provide a much higher precision for the multiplication and the likelyhood of musically relevant sighnal components getting “chopped off” is much less likely and even less audible.
Plexamp adds yet another 8 bit to the precision and uses floating point math instead of integer, which raises the quality into regions where it is IMHO utterly pointless to aim for bit-perfect playback.
I’d wager that your loudspeakers (and the room they’re situated in) play a much more important role in achieving enjoyable sound quality than avoiding digital multiplication at 32 bit precision.
Thank you for the insights. I understand your points about the 24bit precision etc, and I am not ignoring them. But I want to make sure I understand your point–so even if I have 0db on the preamp gain within the app, I wont have bit perfect?
As for my loudspeakers and listening room–I use headphones primarily, so the room is my head I guess, and the speakers are my headphones. I don’t understand the math of floating point v integer, but your points are helpful to contextualize what you’re saying. I am just really finicky and I want bit perfect if/when possible
If you have replay gain activated, there is always going to be a change of volume during playback. Because that is the point of replay gain: to adapt the loudness of each track to a common baseline, to prevent jumps in perceived loudness between tracks when playing a mixed play queue.
Okay, thank you for clarifying for me, I appreciate you.
I saw this remark just now.
Integer math doesn’t know fractions. It is therefore much easier and faster to do by a machine. (Which makes it also cheaper)
Pretty much all music file storage formats use Integer (yes, even FLAC). There are very few exceptions to this rule, and these are commonly only found in audio production products.
The drawback of Integer math is of course this: it handles multiplication badly. And it has a finite range of values, determined by the number of available digits.
If you perform a division (i.e. a multiplication by a factor<1) in Integer, the result is less accurate. Because everything that would go right of the decimal point is thrown away.
If you perform a multiplication (by a factor of >1), you always have the risk of exceeding the available range of values. In the audio domain this means “digital clipping”.
Floating point math is how you know it from school. There is a decimal point, and division/multiplication by uneven factors usually results in growing numbers of digits after the decimal point, the more often you perform it.
It is good practice for Recording engineers to capture audio, at higher bit rates and frequencies than redbook and to use floating point math in production of music as otto said. After production when the engineers deliver the music it is common to “bounce” or “dither” the music down to Redbook standard.
Redbook is more commonly known as CD quality which is 16bit and 44,100 Khz and can be integer or floating but most common is integer. Engineers capture audio at 24bit and 96khz as this leaves enough information to manipulate the music before you go into mastering and keeps the file sizes manageable. Floating point captures a wider range of Decibels than integer. Think of it similar to pictures. There is RAW and then the picture is compressed down to JPG or PNG. Photographers capture in RAW so they have more information in the image file to manipulate the image.
Alot of engineers use higher than 24/96, but only for major artists and music that needs the fidelity (more decibels). That file is then further compressed,bounced, dithered for the various streaming services in various formats. A song can be dithered or bounced in various file types and various encodings.
Here is a general list of the common music file types in music production
Here is a list of the generally used Encodings
Each one of these has its pros and cons and use case. The cool thing is that Plex analyzes the music files and figures out what kind of file it is and what kind of encoding it is. Here is one of my files from my server.
See where it says container and audio profile? That file is a purchased song from Qobuz. And that is what the engineer gave to Qobuz to distribute. Qobuz gives you a choice of format, my preference is for AIFF files. So this music file is Pulse Code Modulation which is the most common for music. Its 24bit 96khz. and the ‘be’ in the audio profile is signalling Big Endian. It is hard to tell if this was recorded as floating point or not but the assumption and general rule of thumb is that it was, and that it was bounced using integer math for the final audio file. But then again the choices the audio engineer made on how they recorded and what they bounced down to are hard to figure out for sure.
