What sample rate and bit rate does Gadget use?

jwmmakerofmusic

I tried to Google this, but nothing doing. Since I use a 2nd Gen iPad Pro, I have more power for processing. While humans can’t hear above 22kHz, effects processing goes a lot smoother when doing 64-bit processing with a sample rate of 96kHz. At least in my experience. Even 48kHz could make effects go smoother. Does anybody know what Gadget’s default sample rate is? And is there a way to change it if it’s stuck at 44.1kHz? Thank you in advance.

TheAudioDabbler

So I just created a little one bar loop, exported it to audio share and it was 44.1, obviously audio copy only supports 44.1 as well. If you go to export to Dropbox, you get more options like 48k and 96k and also 16bit and 24bit.

So it seems it supports a higher rate, maybe depending on the destination app or the audio interface you are using as well.

[Deleted User]

The user and all related content has been deleted.

jwmmakerofmusic

@gmslayton said:
So I just created a little one bar loop, exported it to audio share and it was 44.1, obviously audio copy only supports 44.1 as well. If you go to export to Dropbox, you get more options like 48k and 96k and also 16bit and 24bit.

That really blows. I mean, when it comes to Audiocopy, everybody knows it limits sample rate and bit rate. However, Audioshare supports far more formats than just 16-bit/44.1kHz. The fact I have to upload to Dropbox first is a major pain in the arse, lol. Exporting to iTunes is also very useless, because I haven’t used a PC in literally months.

LucidMusicInc

You can export to AudioShare up to 24 bit iirc

Samu

@LucidMusicInc said:
You can export to AudioShare up to 24 bit iirc

Not from Gadget as it limits to 16-bit@44K when selecting AudioShare as the destination

iTunes and DropBox support the other settings.
(If Gadget had Files.app support the 'iTunes' option would enable us to export 24-bit@96 and them move the files to AudioShare or other destinations without using a computer).

So if 24-bit or 96K is needed DropBox & iTunes are the only options for now...

I do suspect Korg uses 'oversampling' when exporting at higher sample rates instead of a lazy sample-duplication or bit-padding. Internally Gadget most likely uses 32-bit floats like most iOS music apps do...

Telefunky

@jwmmakerofmusic said:
That really blows. I mean, when it comes to Audiocopy, everybody knows it limits sample rate and bit rate. However, Audioshare supports far more formats than just 16-bit/44.1kHz.

You mess file format with internal processing of apps - 2 completely different things
In playback you can't tell 44.1 from 48k, but you can if any higher rate than about 70k is used. Above that rate you can't tell 88 from 96 or 192.

Digital signal processing is ambigous by nature and produces artifacts called aliasing, a flipping of frequencies in the 'wrong direction'. A part of the signal is mirrored downward into the audible range with 44/48, but from 70k upwards it ends in the ultrasound range of the spectrum. It's just math... and a bit of design.

The higher sample rate doesn't necessarily produce a better (or more precise) result, it just happens that you can't hear the flaws anymore.
A lot of IOS apps use 96k internally, but as that increases load it's used for critical parts in the first place, like resonating synth filters and avoided for the more general stuff.
An app can even switch to lower rate processing if it detects the device hasn't enough CPU juice.

It's rather easy to tell by ear, even if the figures aren't published (as with PPG synths), while Zeeon is advertized with oversampling. Turnado (at least the original version) and FluxFx aren't oversampling.

Same applies to the internal (!) bit depth of DAWs which mostly is 32bit float, but other versions are possible.
Not shure about IOS, but on desktop there are various versions using either float or fixed point formats.
What an app exposes externally is not related to internal processing.
A 16bit file may well be handled by a 32bit filter process or compressor.

AndyPlankton

If using IAA this will usually if not all the time be limited to 44Khz 16 bit too...not entirely sure if this is IAA in general or specifically when using it with Cubasis.....if you set you project in Cubasis to 48Khz...then try and load an IAA audio source it gives a warning about IAA wanting 44.1Khz

TheAudioDabbler

I just used AUM to record a loop with Gadget loaded as an IAA Generator. I had AUM set to 24bit-48k and when I opened it up in audio share, the file showed 24bit-48k.

AndyPlankton

@gmslayton said:
I just used AUM to record a loop with Gadget loaded as an IAA Generator. I had AUM set to 24bit-48k and when I opened it up in audio share, the file showed 24bit-48k.

It is difficult to know exactly what is being used where as the hosts may well convert the audio they receive into the format that you specify for your project......I had an issue with Reslice when running as IAA in a Cubasis project..the project was 48K...and Reslice just wouldn't play ball....huge crackle fest. Setting Cubasis to 44k and it worked fine. So some apps just don't work at 48Khz when used as IAA Nodes

This is from Steinberg forum....in an article about IAA Limitations....
• Inter-App Audio routing performs best with a sample rate of 44.1 kHz. Other values might lead to crackling noise.

Thjis suggests that 48Khz is possible with IAA but not recommended. As I said before I'm not sure if this is IAA in general or Cubasis implementation of IAA....

@LFS, @j_liljedahl , @Brambos - Anyone able and willing to clarify ?

j_liljedahl

AUM recordings are done using the same sample rate as the current audio session. In the future I'll add an option to convert it (some newer devices are stuck at 48kHz in some configurations, but you might still want to record 44.1kHz files). The bit-depth only affects recording. Internally AUM is always using 32-bit float.

I would assume most IAA apps and AU plugins also use 32-bit float internally, since that's the natural choice for DSP work (generating or processing sound).

IAA supports 48k and 96k just fine in theory, but some specific apps don't. An IAA app has the choice to follow the sample rate of the host and adapt to it (for example run itself at the higher sample rate without affecting the tuning of its notes), or to stick with a fixed rate (often 44.1kHz) and allow the system to convert the sample rate on the fly. I've collected some technical notes here: http://lijon.github.io/iaa_sample_rates.html

AndyPlankton

@j_liljedahl said:
AUM recordings are done using the same sample rate as the current audio session. In the future I'll add an option to convert it (some newer devices are stuck at 48kHz in some configurations, but you might still want to record 44.1kHz files). The bit-depth only affects recording. Internally AUM is always using 32-bit float.

I would assume most IAA apps and AU plugins also use 32-bit float internally, since that's the natural choice for DSP work (generating or processing sound).

IAA supports 48k and 96k just fine in theory, but some specific apps don't. An IAA app has the choice to follow the sample rate of the host and adapt to it (for example run itself at the higher sample rate without affecting the tuning of its notes), or to stick with a fixed rate (often 44.1kHz) and allow the system to convert the sample rate on the fly. I've collected some technical notes here: http://lijon.github.io/iaa_sample_rates.html

Thank you

[Deleted User]

The user and all related content has been deleted.

j_liljedahl

@tja said:

@j_liljedahl said:
AUM recordings are done using the same sample rate as the current audio session. In the future I'll add an option to convert it (some newer devices are stuck at 48kHz in some configurations, but you might still want to record 44.1kHz files). The bit-depth only affects recording. Internally AUM is always using 32-bit float.

I would assume most IAA apps and AU plugins also use 32-bit float internally, since that's the natural choice for DSP work (generating or processing sound).

IAA supports 48k and 96k just fine in theory, but some specific apps don't. An IAA app has the choice to follow the sample rate of the host and adapt to it (for example run itself at the higher sample rate without affecting the tuning of its notes), or to stick with a fixed rate (often 44.1kHz) and allow the system to convert the sample rate on the fly. I've collected some technical notes here: http://lijon.github.io/iaa_sample_rates.html

Is there some way to check, if an App really put out some bitdeep and frequency instead of being converted by the system?

Not in any easy way. In theory one could make an analyzer AU plugin that could detect the bit resolution and frequency contents.