Encoded audio is softer than source audio no matter the encoder used

[ColtBrony]

Hey all,

so I have a weird and annoying issue where, whenever I encode songs (to put on my phone to be played by foobar2000 on Android), the encoded audio files are noticeably softer than their source files, and nothing I seem to do regarding adjusting settings or the like seems to bring any solace. Help would be greatly appreciated!

If it makes a difference, I have upgraded my mobo, RAM, and CPU near the end of August and have had the issue since that point.

Many thanks, and kind regards!

Edit: The files I am looking to get encoded are M4A (iTunes) files.
Edit the second: the newest continuous build for Windows x64 did not alleviate the issue, nor does changing the encoder's presets.

[Freddiefora]

Depending on the codec used. FLAC should sound crisp and clear if you use the '0' setting, Apple Lossless should sound natural. Your hardware upgrades should not have made a difference, unless you are listening via the inbuilt audio facility. Check that you have the latest driver or use an external DAC connected to your computer.

[Lee-Carre]

Depending on the codec used. FLAC should sound crisp and clear if you use the '0' setting, Apple Lossless should sound natural.

Nonsense; lossless codecs should all sound the same. By their very nature. The waveform they output is identical to the input/source.

Your hardware upgrades should not have made a difference, unless you are listening via the inbuilt audio facility.

Heh, should. Famous last words.

Should test, instead of assuming. Hardware bugs & glitches exist (Intel's infamous 0xF00F bug comes to mind). Manufacturing defects do occur.

When trying to control variables, this kind of change is a significant distraction, and greatly increases uncertainty.

Check that you have the latest driver or use an external DAC connected to your computer.

Again, more changes, when the problem is that something's changed.

A shotgun approach isn't effective when trying to isolate & diagnose a problem.

Evidently some change happened which caused this observed difference. An unknown one. Changing more variables (instead of keeping them steady) only adds more uncertainty.

[Lee-Carre]

the encoded audio files are noticeably softer than their source files

What does this actually mean? Precision, please. I say that as someone with multiple relevant backgrounds to this project.

• Quiter?
• different frequency-response? (If so, in what way?)
• less dynamic range?

Encoded audio is softer than source audio no matter the encoder used

Different encoders for the same codec, or different codecs?

If the former, then it's not likely to be an encoding problem. If the latter then it doesn't even depend on codec.

The commonalities are other aspects; such as the source files, the playback device, and whatever analogue listening equipment used.

What happens when listening to each (source and encoded) on the same host/device?

I have upgraded my mobo, RAM, and CPU near the end of August and have had the issue since that point.

Thoroughly test your hardware.

• Prime95 for the CPU (does it correctly computer the same result as the already-known answer?)
• MemTest86+ for RAM; you want to let it do sets of 32 passes (so it tries every pertubation of some tests; I speak from experience of when a particular pass-count interval was the only one to find a 2-address fault in some modules I had, which were causing all sorts of software problems; the problem only occurred when writing a specific data pattern to the dodgy address (which returned a different value when being read); after replacing the modules and determining (via yet more testing) that the new ones were fault-free, all sorts of weird software misbehaviour disappeared; so, yes, you want to test the hell out of your RAM); depending on RAM capacity, and performance, it may take quite a while to achieve a few multiples of 32-passes
• you may wanna check various configuration is the same on the new mother board, as the old one, unless you were upgrading
• there's other testers, for other sub-systems (like HDDs), but I'm not sure that they're relevant, here.

The files I am looking to get encoded are M4A (iTunes) files.

Could be some crApple weirdness, then.

Are you playing each file using the same software? I'm wondering about ReplayGain being added/removed while transcoding.

Another thing to try, for testing, is to re-encode to the same codec as the sourrce (M4A), but to a different file, then compare the source with what should be a closely similar file.

If, in iTudes, you generated those M$As from a CD, then try using the CD as the source with Fre:AC (instead of transcoding).

Basically, try to narrow down where the source of the difference might be, in order to isolate it.
Compare a car; it's unlikely that every part has failed, so start by checking the basic obvious stuff; does it have fuel, is the battery charged and outputting nominal voltage, do any of the electrics work, does the starter motor engage at all, does the crankshaft turn when trying to start it, … you get the idea.