SoundCloud clipping sound on MacBook Pro with M-Audio Air interface

B

brianmedd

New member
Hi HomeRecording.com,
I've made this account to ask you guys about a problem I've been having since day 1 once I got the new MacBook Pro M1 Pro.
I have noticed a LOT of clipping when sound gets loud / peaks, but I can't find the solution to this. The problem especially occurs when listening to (what I have found) one song by Snavs on SoundCloud ( ).
Throughout the whole drop, the sound is so distorted, it is unbearable to listen to.

PS's:
- This happens in both Safari and Google Chrome.
- I'm using M-Audio Air 192/4 with the belonging USB-C.
- I have set the audio to 48.000 Hz (standard) and tried 44.100 Hz and so on, but nothing changes.
- I have tried to plug the USB-C in all three Thunderbolt outputs on the MacBook.
- I'm using KRK Rokit 5 G4 as monitors with balanced XLR.

EDIT EDIT: This does not happen when listening on the MacBook speakers.

Hopefully you can help!

Best regards,
brianmedd
 
Last edited:
mjbphotos said:
If its mixed/recorded with clipping going on, you can't fix that when listening.
Click to expand...
Sorry, I've made a mistake. The song sounds fine on MacBook speakers... Also on Spotify. On Spotify both MacBook speakers and Rokit Monitors sounds fine. So there seem to be a conflict between SoundCloud and maybe M-Audio.
 
Spotify will change the loudness of your file, SoundCloud does not. Not sure what/how you are playing on your Macbook, but that doesn't mean much to a cloud service that is manipulating a file they have.

Put a link to the MP3 or whatever file you uploaded to SoundCloud so we can see what you actually uploaded. If it has peaks over 0dBFS, it's going to sound clipped. Even if it's been normalized to a peak of 0dB, it will have "true" peaks above, and then when your streaming platform re-squashes the song, it's going to sound clipped, possibly more than it did originally.
 
keith.rogers said:
Spotify will change the loudness of your file, SoundCloud does not. Not sure what/how you are playing on your Macbook, but that doesn't mean much to a cloud service that is manipulating a file they have.

Put a link to the MP3 or whatever file you uploaded to SoundCloud so we can see what you actually uploaded. If it has peaks over 0dBFS, it's going to sound clipped. Even if it's been normalized to a peak of 0dB, it will have "true" peaks above, and then when your streaming platform re-squashes the song, it's going to sound clipped, possibly more than it did originally.
Click to expand...
Not sure how to get the MP3 as it isn't my song. I don't know if recording on the computer into Audacity or something like that will result in the way you wanted to hear the file?
 
If it's not your song, there's no way to know what was uploaded to SoundCloud.

I can no longer understand what the exact configuration is that you are using which does not sound good? Aren't the Rokit monitors connected to your M-Audio interface?

The sample rate of the interface has nothing to do with the sound when it comes back from the computer.
 
I've been having the same issue with my MacBook Pro and M-Audio Air interface. It's really frustrating because it happens with almost every song I listen to, and it's really noticeable when there's a lot of sound happening at once. I've tried messing with the audio settings but nothing seems to make a difference. Has anyone else had this problem and found a solution?

--
Jason Hook. I enjoy remixing old songs using Audacity together with UnMixIt for vocal removal or isolation
 
keith.rogers said:
If it's not your song, there's no way to know what was uploaded to SoundCloud.

I can no longer understand what the exact configuration is that you are using which does not sound good? Aren't the Rokit monitors connected to your M-Audio interface?

The sample rate of the interface has nothing to do with the sound when it comes back from the computer.
Click to expand...
Im using my M-Audio interface with Rokits as monitors, and that connection seem to distort when there's a lot of sound happening at once like TheSynthDev says.
 
I used a Soundcloud downloader to look at the song. Its MASSIVELY distorted. This is section at around 40 seconds in. It's consistently flat topped like this for the majority of the song. It's no wonder that sounds like dog poop!

Snaves and Kage.jpg
 
Since I can actually hear it on my laptop, that clip-distortion comes across as just another 'sound' to be incorporated into this genre's palette. Like that zipper noise I used to get when I overloaded my Stereo VCR on mixdowns.
 
I looked at a number of posts of Snavs songs from the list on the Riotville Records page and the majority of them are maxed out, although not all were clipped as badly as that post. Still, it's the epitome of the "loudness war" sound. If the track doesn't look like flat land, it's just not loud enough!!!

It doesn't have to be that way. I have heavy metal albums that are clear, don't pump and aren't clipped. They just sound good.
 
I'm unfamiliar enough with this genre to make the bold assumption that it's the creator's intent to have it end up sounding the way it does.

Short answer is the content that is coming from both of these sites, while the same song, is not identical. So, what is causing the problem, and is it SoundCloud's fault or something with the D/A in the interface or a fault that is being displayed by the speakers in this instance, I don't know. You'd have to take some time swapping hardware around to see what's going on.

Both versions of the song are similar, and likely have just taken different routes after bouncing out of the mastering phase, if they didn't split there, i.e., different masters for different targets. It's clear that what is being streamed is not the same.

I just recorded off my headphone jack, which I left unchanged, and recorded it as MONO on my Zoom F8n. I recorded them low enough that my limiters (on all channels and I don't want to mess with settings and forget..) did not kick in. Then I normalized the Spotify version up to -1dB peak, almost 5dB gain. I applied the same gain to the SC and it ended up at -1.08dBFS peak. Viewing in Ozone, it's obvious the SC version has taken more of a beating in the trip to lossy streaming (IMO).

And they do not sound the same. The Spotify version, at a -1.0dBFS peak normalization, measured exactly -17.0 dB LUFS, while SC's measured -17.3 dB LUFS. (Actually a measurable amount "quieter!") In addition, the Spotify clip is lopped off pretty quickly around 15.5kHz while the Sound Cloud one extends out to 16.5kHz! (If I have not gotten them mixed up.) I did not look at subsonic content, which is where I can imagine things can get weird, and possibly one source of what's making the Rokit's jump about.

The captured files images are attached. ride-sy = spotify and ride-sc = sound cloud.

Pure speculation because we don't know what was uploaded to each service, but we can probably assume that with Spotify's billions, they have better compression algorithms at work, so that may be a part of it.
 

Attachments

  • ride-sy.jpg
    ride-sy.jpg
    433.8 KB · Views: 4
  • ride-sc.jpg
    ride-sc.jpg
    431.6 KB · Views: 4
Last edited:
Keith, did you look at the peaks to see if they were clipped? Since you did a capture from the headphone output, your level could well be lowering the max levels, but if they were clipped it should still show up.

I downloaded the mp3, and when I measured it, I got a LUFS of -7.4, not -17.3. Looking at the spectrum with BlueCat's analyzer, it has a sharp cutoff at 16K, but had high levels all the way to 10 Hz. Also, the loudness true peak of +2.1 was pretty much duplicated with the RMS metering in Reaper, which showed a +2.5dB max peak. I know that comes from the MP3 reconstruction.

When I listen to the Soundcloud output and compare to the mp3, they sound exactly the same.

The Ride.jpg
 
Just one last item, the mp3 download is at 128kbps which totally explains the 16kHz cutoff.

Some past testing information gave these numbers;

bit rate- - cut-off frequency- - compression ratio
1411kbps - -- >20kHz -- - 1:1 CD PCM Audio
320kbps - -- 19.5kHz -- - 1:4.4
192kbps - -- 18kHz -- - 1:7.3
160kbps - -- 17kHz -- - 1:8.8
128kbps - -- 16kHz -- - 1:11
96kbps - -- 15kHz -- - 1:14.7
64kbps - -- 11kHz -- - 1:22
32kbps - -- 5kHz -- - 1:44
 
keith.rogers said:
I'm unfamiliar enough with this genre to make the bold assumption that it's the creator's intent to have it end up sounding the way it does.

Short answer is the content that is coming from both of these sites, while the same song, is not identical. So, what is causing the problem, and is it SoundCloud's fault or something with the D/A in the interface or a fault that is being displayed by the speakers in this instance, I don't know. You'd have to take some time swapping hardware around to see what's going on.

Both versions of the song are similar, and likely have just taken different routes after bouncing out of the mastering phase, if they didn't split there, i.e., different masters for different targets. It's clear that what is being streamed is not the same.

I just recorded off my headphone jack, which I left unchanged, and recorded it as MONO on my Zoom F8n. I recorded them low enough that my limiters (on all channels and I don't want to mess with settings and forget..) did not kick in. Then I normalized the Spotify version up to -1dB peak, almost 5dB gain. I applied the same gain to the SC and it ended up at -1.08dBFS peak. Viewing in Ozone, it's obvious the SC version has taken more of a beating in the trip to lossy streaming (IMO).

And they do not sound the same. The Spotify version, at a -1.0dBFS peak normalization, measured exactly -17.0 dB LUFS, while SC's measured -17.3 dB LUFS. (Actually a measurable amount "quieter!") In addition, the Spotify clip is lopped off pretty quickly around 15.5kHz while the Sound Cloud one extends out to 16.5kHz! (If I have not gotten them mixed up.) I did not look at subsonic content, which is where I can imagine things can get weird, and possibly one source of what's making the Rokit's jump about.

The captured files images are attached. ride-sy = spotify and ride-sc = sound cloud.

Pure speculation because we don't know what was uploaded to each service, but we can probably assume that with Spotify's billions, they have better compression algorithms at work, so that may be a part of it.
Click to expand...
It's annoying that there are different outcomes just by letting the M-Audio Air be in control, so I guess this is up to be a money problem in the end with having to buy a better interface?
 
But the weird thing is that my M-Audio and Windows computer worked fine until I made the switch to MacBook. The combination of M-Audio and MacBook is possibly not that well in the end...
 
Brian, I don't use Macs, but I was wonder if there is some issue with the M1 Mac's compatibility with the M-Audio? I know that there are other things that have broken with the change in processor. Are you operating in native mode or Rosetta compatibility mode?
 
Native. Just the standard M1 Pro chip
"... if there is some issue with the M1 Mac's compatibility with the M-Audio?" Yes probably.
There's so many question marks.
The Air 192/4 is class compliant so I can't figure out where the problem lies.
 
Last edited:
TalismanRich said:
Keith, did you look at the peaks to see if they were clipped? Since you did a capture from the headphone output, your level could well be lowering the max levels, but if they were clipped it should still show up.

I downloaded the mp3, and when I measured it, I got a LUFS of -7.4, not -17.3. Looking at the spectrum with BlueCat's analyzer, it has a sharp cutoff at 16K, but had high levels all the way to 10 Hz. Also, the loudness true peak of +2.1 was pretty much duplicated with the RMS metering in Reaper, which showed a +2.5dB max peak. I know that comes from the MP3 reconstruction.

When I listen to the Soundcloud output and compare to the mp3, they sound exactly the same.

View attachment 115590
Click to expand...

Well, in short, it beats me.

I didn't capture the digital signals, but the analog output from my Steinberg UR44C of both sources. I think whatever clipping can be seen, it's "baked into" the original mix/master. Yes, I turned the levels down, because I didn't want what I recorded to show clipping that was a result of my own fumbling. As I said in my first post, we know Spotify levels output. I don't think SoundCloud does - reportedly it doesn't - and my [A/D] recording suggests that the output level there is about the same as the Spotify version, which OP says doesn't cause distortion. That actually surprised me, because I thought I'd see a much louder SC track.

I had the level set on my headphone output and gain on the Zoom F8n so it would not clip. I recorded both the output from SoundCloud and Spotify with the same settings, and level-wise, they were about -12dB LUFS. It depends how I scale the output how it looks, and I did a mono recording, so some cancellation may have occurred, removing some flatness. The point was, the digital streams would have gone to the DAC in my Steinberg, and if they had been the same, the audio would have been the same, or certainly not as different as what I saw. What we don't know is whether Spotify and SoundCloud got the same original file, i.e., did Spotify get a non-lossy, 24-bit upload, and SoundCloud an MP3 of that, or what?

So, my main point is comparing a stream from two different services doesn't matter in this case. They're both probably pretty low quality, like 128kbps stereo! The question is what is causing the problem on OP's computer. Given all the positive comments on the SC track, I don't think the noise is in the stream itself - most people hear a very distorted track of music and find the Spotify and Soundcloud versions essentially the same. If I had to point fingers, it might be at the M-Audio, but it could be a combination of something like subsonic content that's is filtered by Spotify's compression (as they seem to trim a bit off the top, too) that's a bit much for the Rokit pair.
 
You must log in or register to reply here.
Back
Top