My proposed improvement would be to let users set the fade curves for smart fades, the same way we already can for traditional Crossfade, or have the option to disable the volume fade altogether like the flat curve does.
Problem solved:
On a song with a long tail, where the end hits the smart fade threshold, the ending is currently faded out unnecessarily. Similarly, if a next track starts loud, it fades in unnecessarily.
Because of the way smart fades intelligently sets the time of overlap, at least one of both tracks in either case should be so quiet that even played without volume fades there should be no chance for clipping. Therefore they could play the ending tail of track A over the beginning of track B in full, with neither having to sacrifice any dynamic information to achieve this effect.
Brought benefits:
This would give users some more flexibility with the effect they want from Smart Fades, the same way we already have these curves for standard Crossfade. “Auto” could remain a fade curves option for those who prefer Smart Fades’ default behavior. Ultimately it makes one of Symfonium’s coolest features more tailorable for the user’s preference.
Other application solutions:
This “no-volume-change” smart crossfader is the same idea behind Plexamp’s “Sweet Fades” and Foobar’s foo_dsp_crossmix component. Both find the threshold where Track A’s end and B’s beginning are low enough in volume to safely overlap and prevent fading to silence. Then, track B is started early enough so that their threshold points overlap.
I’d like to provide an example of the probem from not having this setting available. We’ll consider a playlist of two songs (not a very good one for listening but it highlights the issue and is applicable to any other songs that end or start with the same dynamics.)
For the fade out, let’s use Hopes and Dreams (etc) by Toby Fox, David Peacock and Augustine Mayuga Gonzales (links to Spotify). It’s a piano arrangement that ends with a long sustain to silence. Smart Fades, like Plexamp or Crossmix, will correctly identify that the right time for the next track to come in is a whopping 15 seconds before the end of the actual track. That’s a very long tail!
Smart Fade already handles the timing aspect, which is excellent, but with no control over the fade curves, what we get is that Hopes and Dreams’ tail gets sloped down and over 10 seconds of it gets lost, meanwhile because Time Machine fades in we lose the initial loudness and even the first word of the song becomes harder to understand.
With the normal Crossfade settings already available, I could dial in a 15 second fade out with the flat curve option and get that same crossfade point but without any actual fading applied, but obviously that 15-second duration will only work for songs with 15-second tails like my example, and the next song might not start instantly like Time Machine. That’s why the timing aspect that Smart Fades provides is so essential.
These are extreme examples, and maybe not so many songs fade out so long, but a lot of them start loud and might be more enjoyable listening if they played full volume on the onset. That’s why I think it’s a worthwhile improvement to have the curve options like we have on standard crossfade available for Smart Fades.
I’m back after demoing the “Mix Only” feature available in the new beta. Thank you for the implementation! However, I’m finding some issues with the new feature, and I believe I may have assumed incorrectly how smart fades decides its points to activate. I’ve got my DAW open to make some visual examples:
The first issue is the more egregious of the two. In this example I was listening to a couple dance songs, and noticed that Symfonium started the next song earlier than anticipated. This is early enough where they’re both basically full volume and it does risk clipping on playback. Ideally, the trigger point would be more like the above two waveforms where track A should be tailing off and then track B comes in at full volume.
For the second example I tested that boundary between the “Hopes and Dreams” track from my original long tail example and the track that follows it in my playlist. Again, the early start is noted (though the next song starts so quietly that this is more understandable), but what caught my ears right away was how track A’s tail was truncated. The default sweet fade would’ve hid the cutoff, whereas the mix only mode calls attention to where it stops playing track A in this case.
All of this has made me realize that this is a bit more complicated than simply turning the fades off on the smart fades function. The trigger point is different, since it’s not looking for the ideal point where track A can effectively crossfade into track B, but where they’re both quiet enough to overlap without distortion or anything else. I misunderstood that when listening to smart fades originally. And then the tail truncation issue would have to figure out how much is left of track A to buffer or something so it doesn’t cut off early.
Remember that this is a phone app and does not have the full power of a server, so even the amplitude is a lot less precise and approximate. It is not possible to have a perfect solution.
With that said with current version clipping should never occurs. Upload the problematic songs to https://upload.symfonium.app with a description and tell me exactly the cases with the song names here after.
Yeah, that’s a fair point. the platform alone leaves us with less tools to deal with the nuances here.
That being said, I really don’t know how smart fades picks the right moment to activate. I assumed it was based on a volume threshold on the starts and ends of each track? If that were the case, the early-start problem could be solvable by lowering the threshold just for the mix-only mode. That way we’re not just preventing clipping (and you’re probably right that it isn’t), but also preventing a loud end of one track and a loud start to the next from jumbling over each other too much. Instead the overlap point would be pushed out to almost right at the end of the first track’s runtime where track B can come in right on track A’s tail.
I’ll upload the offending tracks shortly with a description. If it can’t be done I understand, but if it can be done that’d be cool (and you’d also be the first to make it work on an offline mp3 player app, far as I can see)
