Everytime i export as wav it changes key and tempo when i play the downloaded converted file? gor example a song created in Am BPM 120 converts to F# 110? its driving me nuts. Cheers.
I’ve also had this problem before with Hookpad 1 and it happened to me as well the first time I tried exporting to mp3 in Hookpad 2.
I recall at one point they had changed the wav export in Hookpad 1 so that it didn’t have to play the song before exporting the file, it just prompted you to select a folder and filename and then saved the wav file immediately. It worked great while it lasted but then the development team changed it back to the original way for some reason, and it’s been so buggy for me that I’ve taken to just playing the file and recording it using Audacity rather than trying to export it directly from Hookpad.
1 Like
Hi all, we’re aware of this issue and are actively looking into it. Sorry for the trouble
1 Like
The exported MP3 files are always at 44.1 kHz instead of whatever the system uses (on my computer this is 96 kHz so everything is transposed more than an octave below).
Come on guys, i need this for a kompoz collaboration and your holding me up…its been a waaaaaaaaaay too long this issue has gone unfixed how can you release a paid subscription to something which is majorly faulty, if i knew i couldnt export wysiwyg and instead have to calculate which key it changes it to and the tempo…well, i wouldnt have subscribed. Hint hint, do you see what im getting at, i reckon a few months extra added on to my subscription will keep me sweet and id be happy to continue subscribing. call it a good gesture choice. all in all its a bloomin good system.
bloody good idea, well done.
@HertzDevil, thanks for the tip. Indeed the problem was that the sample rate of the export is hardware dependent, and that support for specifying sample rate in the Web Audio API is not yet supported (https://github.com/WebAudio/web-audio-api/issues/300). Apparently the most common non-44.1k sample rates are 48k (causing a minor second detuning), and 96k (around a minor 9th detuning), which likely explains this effect in some user exports. We’ve built a workaround that looks up the user hardware sample rate, then downsamples the data accordingly as it encodes to mp3 until the Web Audio API supports specifying sample rates. This fix so far is working on the only system we have that runs at 48k, but we’re optimistic that this will fix this issue for all users.
We’ll be pushing this update tomorrow afternoon along with some other bug fixes. Thanks again for your patience
@adam_risch, yeah back when we were using Flash to render the audio performance, we had access to the entire audio buffer before it was played, so we could directly write it to file. Now that were are using the Web Audio API, the only way (that we know of) to get access to the audio buffer is to have it rendered through audio chain during an actual performance, which unfortunately happens in real time. We briefly experimented with playing the performance twice or three times as fast, then downsampling later, but found that it caused too many performance issues on slower computers.
Hi all, this code is live, so please let me know if anyone is continuing to have issues.