Calculated waveform image different level than live view

[RyanG2016]

I am using the realtime view to display audio level when recording. If the user playsback the recording, I am generating a waveform image which replaces the liveview during playback. I'm noticing that the levels that come in when recording are not the same as the rendered image. I will attach images but what I mean is the image view and the realtime view are the same sizes and when I'm realytime recording, I rarely get to the top of the container yet when the waveform is generated, the visual represention seems like most of the audio was at full level. I'm probably doing a terrible job explaining this but is there a way to set thresholds for the waveform output so I can match them to what the user would see when recording?

Here is a sample of a realtime waveform:

Here is sample of the generated waveformImage:

[dmrschmidt]

Hey @RyanG2016,

that’s a very interesting problem. I don‘t have a clear answer for you right now, but I’ll look into this a bit more when I find some time.

On first glance, I think one major contributing factor is that the data & calculations for both are vastly different due to very different needs. The live view simply transforms incoming values in real time using straightforward math on already pre-computed samples provided by iOS. So it doesn’t operate on the full raw data. The static view on the other hand works on the full data and does it’s own down-sampling and uses Accelerate framework based computations. The normalization May also have different parameters. So some level of difference is to be expected due to different sample window sizes etc.

To understand the example you posted better, what is the relation between these two waveforms? Is the live view just a snapshot of a full recording? Or is the live view waveform showing a very short <10s I guess complete recording and the static version the rendering of that very same audio file you recorded?

[RyanG2016]

@dmrschmidt Hi! The first waveform is the real-time monitor. It is running every .01S. The level never really peaks and the wave frame is pretty much identical to the one in your example. I guess in order to make the levels look similar I guess you need to factor in the frame height or the live waveform in the formula somewhere. I'm terrible in math so I don't know how much I can help there :)

[dmrschmidt]

There's a few things here at play. First regarding the levels. The two views serve different purposes and are thus behaving slightly differently. They are both normalized differently, which explains why one "never really peaks". This is by design for the use cases I had in mind when designing this originally. Potentially one could make this adjustable to be more flexible for different use cases.

This would be pretty much useless however in the design you have chosen. The Waveform.Style.striped is a purely artistic representation and not at all meant to be accurate. There's a huge amount of downsampling necessary, and depending on how the windows for this are set, the results may vary by pure chance, essentially. That's inherent to this kind of super-rough representation.

So if you are looking for something generally more comparable, you should really be using the .filled or .gradient styles.

Happy to dig into this deeper if this doesn't fit your use case.

[RyanG2016]

@dmrschmidt I will play around with the different waveforms and see if they will work better.

[dmrschmidt]

Very late now :D But any resolution to this since? Any thoughts on how things could be improved maybe? Otherwise I'm probably just going to close this.

[RyanG2016]

@dmrschmidt I've been working in other project since then and haven't even looked at it. That being said, I am going to be starting on a new project in the next month where I will need to incorporate some sort of waveform so I will look at it again then. The new project will be in SwiftUI.

[dmrschmidt]

Thanks for the update. Please come back to this issue when you're running into the same problem and feel the library could do sth differently to support your use case better. For now I will close this issue, but feel free to re-open this one or open another one.