You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A limitation for lower-powered platforms is that selecting an immediate on-the-fly pitch-change for the current track often causes warbling/quality-loss or other audible artefacts, as the conversion is necessarily processor-hungry.
Is there a way to schedule this conversion to be run as a background process (similar to how the downloading of a new file is handled) using spare clock-cycles, while higher-priority tasks such as playing the next track would continue to be run in foreground. The resulting transposed file would need to be saved as a new file (with pitch-change delta declared in the title?) with availability for selection deferred until completion, but it could then be queued for playing as if it was the original just in the changed key.
The dfference would be that the transposition artefacts should be significantly reduced (or perhaps largely eliminated?) as the conversion could take as long as it needs, rather than 'best-effort' available on any given platform while maintaining a live playback, as currently implemented.
Obviously a lower-powered platform would take longer to complete such a background conversion than would a higher-powered one, but the resulting files should be more consistent between platform capabilities in transposed quality.
Regards
Hartebee5t
The text was updated successfully, but these errors were encountered:
A limitation for lower-powered platforms is that selecting an immediate on-the-fly pitch-change for the current track often causes warbling/quality-loss or other audible artefacts, as the conversion is necessarily processor-hungry.
Is there a way to schedule this conversion to be run as a background process (similar to how the downloading of a new file is handled) using spare clock-cycles, while higher-priority tasks such as playing the next track would continue to be run in foreground. The resulting transposed file would need to be saved as a new file (with pitch-change delta declared in the title?) with availability for selection deferred until completion, but it could then be queued for playing as if it was the original just in the changed key.
The dfference would be that the transposition artefacts should be significantly reduced (or perhaps largely eliminated?) as the conversion could take as long as it needs, rather than 'best-effort' available on any given platform while maintaining a live playback, as currently implemented.
Obviously a lower-powered platform would take longer to complete such a background conversion than would a higher-powered one, but the resulting files should be more consistent between platform capabilities in transposed quality.
Regards
Hartebee5t
The text was updated successfully, but these errors were encountered: