< Back to IRCAM Forum

Frequency Shift Inconsistent

I have been attempting Frequency Shifting and have been getting inconsistent, bizarre results. I have attempting rather radical shifts (-400 Hz, -500 Hz, -1000Hz). What I have found is that the shift take an unexpected additional shift at an unexpected spot randomly. This only happens when processed. When I listen to the shift before processing, everything sounds great. After processing, the new file begins fine, but after 30 seconds or so takes an unexpected 50Hz shift up or down. The unexpected shift is consistent throughout the spectrum. I made some files of pure sine waves to test this. The same thing happens. In a 60 sec file of 5 sine waves, an additional unexpected shift occurs at the 42 sec mark. I feel that I am missing something simple here. Any thoughts?


Hi Scott,

Could you please send us the command line of the processing, mainly to ensure there is no other options taken into account and sent to supervp that may produce this strange behaviour.

Also, you can also try when you process your file to revert to the “Factory Settings”.
To do that, you select “Factory Settings” in the “settings menu” which is located at the bottom of the Processing panel and then click Process.
Or, you can also launch the AudioSculpt Menu > Processing > Realtime Processing Settings panel, select the “Factory Settings” in the “settings menu” and press “Set”. It should revert all the parameters for your next processing.

The third option would be also to take a look at the “shiftfile” produced by AudioSculpt. It is located at “AudioSculpt folder”/Temp/shiftfile.
Normally if you create a constant frequency shift for a 50 seconds file the content of the file should be something close to that :
-10.000000000000000 0.000000000000000
0.000000000000000 -1000.000000000000000
50.000000000000000 -1000.000000000000000
If that is not the case could you paste the content of this file here please.

Thanks a lot for your feedback,

Best regards

Thank you for your response. Here is the command line for the processing:
AudioSculpt (1) > supervp -t -Z -S"/Volumes/Glyph-01/Sound/Sound Working/The Conversation Revisited/Audiosculpt/cycle-test.aif" -Afft -Np3 -M0.0416666679084301s -oversamp 8 -Wblackman -P0 -td_ampfac 1 -FCombineMul -Ffshift “/Users/scottsherk/Documents/Temp/shiftfile” “/Volumes/Glyph-01/Sound/Sound Working/The Conversation Revisited/Audiosculpt/test-3.4.5/cycle-test–1000.aif”

total time = 10.23 seconds

I processed a second time with “Factory Settings” and received the same result.

Here is the Shiftfile:
-10.000000000000000 0.000000000000000
0.000000000000000 -1000.000000000000000
60.975601196289062 -1000.000000000000000

Thanks for your help.

Hi Scott,

OK Seems like we have a bug :frowning:

We’ve been able to reproduce it for different values, different timings, and not only when we process but also during a “realtime” processing.

Thanks a lot for your feedback and report.
We will update the engine as soon as possible.

Best regards,

Thanks for addressing the issue. I look forward to the update. In the meantime, any ideas about a work around? I tried using shorter files, but still had erratic results.

Hi Scott,

mmm… i am afraid there is no workaround for now. Unless you find and download an older version of AudioSculpt 3.x whose frequency shift treatment is not broken.
Normally the update should not be too long. We are working on the patch.

Best regards,

Hello Scott,

it turns out the implementation was broken since the very beginning of the frequency shift algorithm (~15 years ago!).
the result was that with increasing duration of the shift operation the precision of the shift did step wise degrade due to the limited precision of the float representation. It is quite funny, that nobody ever noticed that, but the errors become noticible only after a few seconds of audio and probably most people apply frequency shifting over short time frames only.

So the bad news is: old releases will not help. The good news is that the fix was really simple, and the new implementation is now more precise in shifting
and this independent of the length of the treated segment. We should be able to distribute the fix within a few days
(the delay being a function of the other tasks Charles and Frederic will have to deal with).

Thanks for your patience.
Best Axel

Hi Scott,

A new version of AudioSculpt (3.4.6) has been uploaded. It should fix the frequency shift bug.
Could you try and confirm that it does solve your issue.

best regards,

Brilliant! That seems to have done the trick. I tested with sine waves over i minute and found no variation on the frequency shift with either realtime or processed.