I was going through my Google Play Music purchases and noticed a straight line at 16hz see screen shot on almost all my PLAY purchases.
This doesn't seem to happen on my 320 cd rips or even itunes purchases.
What exactly is happening?
1. The main problem with Google Play mp3s is that they are encoded with settings that allow very quick encoding, but as a side effect they have lowest possible quality for 320kbps files - that's accordingly my findings (viewing spectrals from GP, Beatport, Juno, my own rips)
2. Unfortunately distributors of digital content (the ones between labels and shops as GP, Beatport, etc.) seem to never check quality of source material coming from labels. Accrodingly to history of my complaints to Beatport and Juno you may find tracks that contain multiple skips, pops, glitches as well as the ones that are obvious vinyl rips (done with dirty needle or from dirty vinyls) AND WHAT IS WORST of course transcodes - which is best visible when buying WAV/AIFF at Juno/Beatport
3, Music labels don't care too much about quality of what they supply - as seen from above point 2.
What may happen in your particular case (from most likely to less likely to happen):
- it was mastered like that - nothing to complain (at least: no one will accept your complaint)
- track was so specific, that regular LAME encoding caused such stepped attenuation above 16 kHz - nothing to complain
- it was just encoded with FhG instead of usual LAME
- yes, it may be trancode: source PCM -> FhG -> decoded PCM -> LAME
FhG is invoked here as accordingly to my own experience it is FhG (most likely "fastenc" version) which uses that stepped attenuation above 16kHz.
Actually, that looks exactly like the effect of the workaround for the scalefactor band 21 (sfb21) MP3 format limitation, which, at 44Khz, means that frequencies above 16Khz need to be either quantized more than lower frequencies, or you need to overencode lower frequencies (causing the so-called "bitrate bloat").
Just pay attention for one moment to the level at which you're looking. around -90dB
Your spectogram doesn't look that bad. The lowpass alone is a bad indicator to spot poor lossy encodings. Especially, Google-Play-MP3 may don't have that and OGG Vorbis doesn't have it too. ;-)
Do a time/frequency spectogram like Audacity can do on the audio track view. If you find there holes or blockieness in the high frequency, it is very likely having a lossy encoding. If there is a bigger gab between absolute silence and the
lowest frequency amplitudes, the file is very lossy.
I bought exactly two MP3s from google play with a long time period between the purchases... and requested refund both after first listen (I wrote into the request what was wrong with the files)! :P
Bot appeared to be 320kbps but had very terrible artifacts making them unlistenable to me. They sounded like my old -V4 or -V5 encodings from a time where MP3 players had a half GB of disk space and I listened to that crap in school bus.
So I started to inspect them.
I barely remember that there was a meta tag where the encoding parameters were stored and these parameters didn't match high quality 320kbps at all. That was my key event to request refund.
Looking at the spectogram I saw holes everywhere in it while there was no lowpass at all so much bitrate is wasted on extreme high frequencies which are hard to hear ::) .
I believe it is something like this:
1. Vendor delivers any format from ugly 96kbps to high-quality FLAC to google.
2. Google encoded all of them in the past to somewhat misconfigurated -V5 vbr mode with disabled lowpass filter.
3. Google bloated these crappy MP3s up to 320kbps a few years later which doesn't upgrade the quality.
I never buy anymore MP3 files from that store.
Yes, I have multiple albums from Google Play that are clearly transcodes from SoundCloud (ok, the last bit is a guess). The Rich Homey Quan ix tape is an example