Kozso are you saying I should use the H2 by itself, and save the files to the SD card?
Not using Audacity for recording, but open the files in Audacity afterward, to check and process them as needed?
I have been recording with Audacity, and then exporting to an external hard drive, so that allows all kinds of ways for the gremlins to get in. I thought I was ahead of the game by saving to C: instead. Its a wonder the files have been acceptable to ACX.
To back up even further. You in particular have the option to stand-alone record with no change in theatrical voice quality should you discover noises or distortions in your direct-to-computer recordings. The people with a pure USB microphone do not have that option.
I use a rule of twos. Be able to point to two different places where you have valuable work. Network Drives, Cloud Storage, Thumb Drives, C:, each counts as one. My larger Windows machines have C: and D: drives. That counts as two because I can point to two different drives with the cabinet open.
But now, if I record on the freestanding H2, I can evade the whole problem and set it to the 44100 rate. The only reason to use 48000 was that, when H2 and Audacity were both set at 44100, for unknown reasons, Audacity would not let me use the H2 as a mic. It knew it was there and let me select it, but then clicking the red button resulted in nothing at all.
Good evening. I just realized that I built an entire session in the sample of 48000. Now I can't copy/past files into this session from my 44100 sessions. Is there a way I can convert this 48000 session down to a 44100 session? I tried batch process and it looked like it would work, but I got a warning that it would not...and it didn't. I don't want to have to rebuild this session. Any advice would be most appreciated!
You really need our Audition session file guru to answer you. But I believe that it can be possible to edit your .sesx file to change the sample rate of the session. But, of course, only try it on a copy of the file not your original sesx in case it goes wrong. Sesx files are .xml files so can be viewed and edited with an .xml editor app. It may simply be a matter of changing all references to '48000' to '44100'
I use Sublime Text to make the edits. Find and replace works a charm but you should only need to edit that initial line to change the sample rate for the whole session. You can also change from stereo to mono and edit the bit depth.
when working on sound design for video in Logic 9, i use a project template with a sampling rate set at 48000khz. the source material i use vary in sample rate, hence i need to convert it all to 48000khz to match the project sample rate. up until now, what i always did, was to use an external batch audio processing tool (such as the great Sample Manager by Audiofile Engineering) to quickly convert all my material to the desired sample rate. recently switched back to Logic as my main DAW, i wanted to let Logic take care of sample rate conversions when necessary. so, i set my project preferences to include audio assests, copy all used audio files to project folder, etc. and automatically convert sample rates when there's no match. this seems to work properly, however, Logic's conversion also seem to pitch shift (more than slightly) my original material - which never happens when i use an external conversion utility (i usually need to convert from 44100khz to 48000khz). why is that?
It is because logic tries to fit as many 'bits' of sound as possible into the space which the lower sample rate has. The lower rate moved up to higher sample rate will mean that logic will pretty much speed up the original file to fill in the space of the 44100 rate. Kinda hard to explain.
Keep the sample rates to the original size/rate then when bouncing the file down select dither (dosnt matter which type of dither... does all the same thing pretty much) and that should enable you to have a mix of all rates without pitch shifting.
When you import a sample with a different samplerate via drag-and-drop Logic usually converts the file to the corresponding samplerate. However if you import for example a 44.1kHz file into a 44.1kHz session and set the samplerate AFTER this to 48kHz, your 44.1kHz sample won't be converted to 48kHz. This is when it will play back at a wrong speed/tone.
This is odd. In all these years of using Logic I've never faced this problem. The only time it plays files at the wrong pitch and speed is when it doesn't convert on import (tends to do that with MP3s even if include/convert all assets is enabled). Could you post clips of the actual and converted file so we can get an idea of what the problem is?
I switched from USB interface to Dante network and Dante Via only allows sampling rates of 48kHz. Since I've worked in Sonar at 44kHz so far, I now have to change all of my projects. With an audio converter I converted over 1000 wave files from 44kHz to 48kHz in a patch process. In Sonar Preferences for New Projects I have also changed the sampling rate to 48000Hz. If I now load an existing project with the converted wave files, all waves are cut off at the end or set to silence. The file length is retained. If I replace the same file manually via Import audio, the track is displayed and played correctly. So it's not because of the wave file, it is displayed and played correctly in every other player.
What is the difference when Cakewalk loads a project with the associated wave files, or I add the same files manually. In any case, Cakewalk plays the project immediately after opening it, without an error message changed sampling rate. Only the problem that the tracks no longer contain any sound at the end.
in your case, you bought an interface which only supports 48K. so in that case you'll likely have to change the project sample rates on a project by project basis. presumably you're not editing or planning on editing all 200 projects...
1) Change the output format on the inputNode. Although the docs say that this is possible (ref: , text: "The format of the output scope is initially the same as that of the input, but you may set it to a different format, in which case the node will convert."), this actually results in a crash: "'required condition is false: format.sampleRate == hwFormat.sampleRate'"
Also, according to theanalogkid here: , this isn't possible anyways: "We currently don't provide sample rate conversion on an input node - if one destination is a file, use AVAudioFile and let it perform the conversion and move your tap to the input node.", so possibly, the docs are out of date or refer to another situation that I have seen, where inserting a microphone will cause the input node's input format to change to 44100 Hz, but leave the output format as 48000 Hz.
I'm not sure how AVAudioFile can be used to perform the conversion, since it wants samples in the 'processingFormat' which might not match the input node's format especially due to these microphone changes.
1) The reason I needed to use this is because the input node format changes when a microphone is inserted and removed. If this is not taken into account when writing to an output file, then the file will contain audio data at the incorrect pitch and speed.
3) However, if .installTap is called with the input node's input format instead of a nil format, then when a microphone is inserted or removed, the input format will change to reflect that change (and AVAudioEngineConfigurationChange will be posted); however, the ***output*** format will remain the same as the previous format! This is an undocumented way of getting the input node to perform a sample rate conversion, and so far I've only observed this to happen when the HW sample rate changes as a result of a microphone being inserted / removed.
Therefore, I can record to an audio file and not have to worry about performing my own sample rate conversions, even when the sample rate changes due to microphone state changes, as long as the following is respected:
2) The tap should only be created once, after acquiring the session and input for the first time. This is because the tap format must always match the input node's input format, so creating the tap after the HW sample rate has changed means that we'll lose the 'free' sample rate conversion that the input node provides us.
So this behavior helps account for sample rate changes due to the mic insertions/removals without requiring the use of AVAudioConverter. Unfortunately, the input node will only allow a sample rate conversion when it changes the sample rate itself, so conversions to any other sample rates other than the initial HW sample rate will still require the use of AVAudioConverter.
3a8082e126