Use the real track length to scale waveforms #11162
Conversation
…xes the scaling if the track length changes after analysis due to faulty file headers.
…This fixes the scaling if the track length changes after analysis due to faulty file headers.
This avoids unnecessary reference counting.
|
This fixes #11159, or at least the visual aspect of it. Not sure why Mixxx stripping ID3v1.1 tags would cause the track's length to change. How is the track's length computed? It sounds like it might consider the ID3v1.1 tag chunk as part of the track's audio when computing the file's total length, or something like that. |
This has been fixed here:
The library scanner read the length for the ID3 tag. When the rpm is loaded, all frame headers are read and a lookup table for random seeks is build. That the real length is available and replaces the value form the ID3 Tag. |
src/widget/woverviewrgb.cpp
Outdated
| @@ -36,7 +37,7 @@ bool WOverviewRGB::drawNextPixmapPart() { | |||
| // by total_gain | |||
| // We keep full range waveform data to scale it on paint | |||
| m_waveformSourceImage = QImage( | |||
| dataSize / 2, | |||
| static_cast<int>(getTrackSamples() / audioVisualRatio / 2), | |||
| static_cast<int>(2 * 255 * m_devicePixelRatio), | |||
There was a problem hiding this comment.
Why is this multiplied with m_devicePixelRatio for RGB, but not for the HSV and LMH versions of the overview waveform?
There was a problem hiding this comment.
Oh Yes that can be removed.
| const auto lastVisualIndex = static_cast<GLfloat>( | ||
| m_waveformRenderer->getLastDisplayedPosition() * dataSize / 2.0); | ||
| m_waveformRenderer->getLastDisplayedPosition() * trackSamples / audioVisualRatio / 2.0); | ||
|
|
||
| // const int firstIndex = int(firstVisualIndex+0.5); | ||
| // firstVisualIndex = firstIndex - firstIndex%2; |
There was a problem hiding this comment.
There is a check above, that the integer datasize can't be <=1. Therefore dataSize / 2.0 can't be smaller than 1.0. I wonder if a similar check for trackSamples / audioVisualRatio / 2.0 is needed?
There was a problem hiding this comment.
trackSamples and audioVisualRatio are also checked individual.
…of the RGB signal.
|
Done. |
|
Great, can we merge that to 2.3 before release? |
|
Thank you! |
Without this PR, the waveform signal is scaled from the length of the analysis data, while beats and cue points are placed relative to the actual length of the track. In case the track length changes for some reasons the waveform signal will have a building up offset towards the end of the track. This is a visual issue that the beat marker are no longer on the beats visible in the waveform.
This PR fixes the issue by using the loaded track length for all renders in the waveform and waveform overview.
The original decoding issue that may lead to an offset between waveform and audio is not fixed.