First Audio Frame ‘Eaten’ When Using Crossfade / Cue Points #4875
Replies: 4 comments 1 reply
-
|
This is how the waveforms look when recording the differences.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reporting. Please email files to toots@rastageeks.org or as PM via discord. I'll have a look thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the files. I have started an issue here: #4887 Could you report the following:
In particular I'm interested in the first part of the logs and the exact Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
It's fixed thanks! |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
I’m wondering if, in the most recent versions, the very first audio frame of a track might sometimes be getting cut off. While using Liquidsoap in AzuraCast, I noticed this behavior.
I’ve noticed that on some tracks — especially certain MP3 files with a very strong first beat — the punch sounds different depending on whether crossfade is enabled or not. When crossfade is enabled, it feels like the first "micro-frame" is “eaten” or absorbed (even when fade in and cue in are both set to 0).
When I disable crossfade and all custom cue points, that first beat plays cleanly and sounds normal again.
Scenario 1 – Crossfade Disabled:
The previous track has custom cue points (start next + fade out).
The next track plays with the first frame “eaten,” regardless of whether it has custom cue points or not.
Scenario 2 – AutoCue Enabled:
The previous track has no custom cue points.
The next track still plays with the first frame “eaten.”
Scenario 3 – No Custom Cue Points and Crossfade Disabled:
The first beat of the next track plays cleanly.
@toots If this seems relevant, I can provide the MP3 files and the script needed to reproduce the issue.
Beta Was this translation helpful? Give feedback.
All reactions