Summary: Samplitude doesn't handle importing standalone > 2GB WAV files gracefully. But...there's no reason to use WAV files > 2GB file within Samplitude since it's virtual project (non-destructive) editing environment allows for
projects > 2 GB. More details below...
WAV Files > 2 GB
I was unable to open within or import into Samplitude an existing WAV file > 2GB (though I've not tried BWF files yet...if ever).
When creating a WAV file > 2GB within Samplitude's WAV Editor or exporting/bouncing from a Virtual Project, it uses the
continue chunk (http://www.noa-audio.com/continue_chunk.html) mechanism to link together multiple WAV files < 2GB. Saving a WAV file > 2GB generates a 2GB WAV file + the appropriate number of WNN files (where NN = a sequence number...01, 02, 03, etc., each no larger than 2GB) to accomodate the full size of the WAV. For example, if one creates a 3GB WAV by taking a 1.5 GB WAV file (A) and appending a second 1.5GB WAV file (B), Samplitude will create a 2 GB WAV file and a linked 1 GB W01 file (again for a total of 3 GB). However, I've encountered a minor issue with re-opening the WAV and WNN files later - opening the WAV doesn't seem to automatically open the continued WNN files. Not perfect, but it is, however, easy enough to open manually the WNN within the same window. (
Edit to add: Opening the original WAV, and Samplitude also opening the linked WNN file worked the last time I tried it.) Might sound like bad news, but...due to Samplitude's object oriented editing model and Virtual Project environment, there's good news!! See next section...
Projects > 2GB
By creating a Virtual Project (VIP) in Samplitude (which one should do to take advantage of its non-destructive editing capabilities), there's really no reason to use WAV files > 2GB. Workflow goes like this:
- Set recorder to generate =< 2GB WAV files (e.g. my R-4 will auto-split at the 2GB threshold)
- Transfer these WAV files to one's computer
- Create a new Virtual Project
- Within the Virtual Project, add each =< 2GB WAV file in sequence (don't forget to turn off Auto Crossfade, or if you forget remove the crossfades in the Object Editor)
- Save the Virtual Project (SASO!)
- Perform any and all edits to the Virtual Project just as one would do if editing a single > 2GB WAV file
- Track, SRC, dither, and bounce/export audio, etc., as usual within Samplitude
Done!
Basically, editing within a Samplitude Virtual Project multiple WAV files that together are > 2GB poses no problems and the workflow one employs is no different than if Samplitude flawlessly handled files > 2GB (which it doesn't quite seem to do).
To work on each stereo channel separately:
Main menu:
File | Convert Audio | Stereo-Wave -> 2 Mono
I ran across SSE configured to old settings after a system restore and had to re-set the following settings. For tracking 16- and 24-bit in the same VIP, simply set the following:
View | Units of Measurement | CD MSF (ensures track markers fall on sector boundaries) *
View | Snap Active (enabled)
View | Snap To | Objects (makes it easier to align the track markers with the start/end of objects)
The first is the only critical setting. The other two are helpful when dividing up a WAV into multiple objects, like I'm doing for an a cappella recording in which I'm splitting the music into discrete objects and deleting the non-music objects. The latter two make it easier to place track markers at the start/end of each object, something one normally wouldn't have to worry about when tracking a continuous recording.
*
Note: When exporting to 16-bit / 44.1 kHz, select a range starting at the first track marker and ending at the last track marker. Then
File | Export Audio | Wave, and in the
Export Sample window select
Export Marked Range and whatever other settings one desires. This will ensure no sector boundary errors on the exported WAVs. For some reason, if one selects
Export Complete Project instead of
Export Marked Range, SSE leaves a sector boundary error on the last track. Dunno why, but...at least it's an easy workaround.
Edit to add: I've found bouncing the tracks (
Tools | Track Bouncing sounds better than
Export Audio. So I now have a two step process to convert from my VIP to individual tracks: bounce the tracks to apply all processing, resampling, dither, etc. into a single, new WAV file (that retains the track markers from the VIP), then from this new WAV file I export (which creates individual tracks, making sure I turn off dithering / resampling).
General notes on SSE handling 16-/24-bit and 32bfp files, overall feature set, learning curve:
SSE handles 16-bit, 24-bit, and 32bfp files just fine and imports each in their native format. It internally processes at 32bfp, so you'll want to dither before exporting to the final desired format. It includes generally the same feature sets I've used previously in CEP/Audition, WaveLab, and Audacity: dynamics (compression, limiting, etc.) amplitude (gain, normalization, fade in/out/cross, volume envelope), parametric EQ, etc., and of course supports a slew of VST or DirectX plug-ins. It's really just a question of getting accustomed to navigating within SSE to find all the same features.
I'd say the biggest shift, and one of the biggest benefits, was learning to work in a non-destrutcive, object oriented model - called a Virtual Project in SSE. And I found it a pretty easy adjustment. One may slice & dice a WAV file (non-destructively) into multiple objects, and apply the same or different edits to those objects. When working with multiple ~2GB files, one simply imports each file into SSE (as separate objects, hence avoiding the whole > 2GB file issue), in sequence (making sure to turn off auto-crossfade), apply any edits one wishes to any / all objects (one may copy edits from one object to another, or make edits to multiple objects simultaneously), define track markers, and bounce (export) the tracks when done (SSE seamlessly joins the two objects when exporting). In the process of bouncing tracks, SSE will apply all the edits defined for each / all objects in the project, and resample / dither as the user defines when initiating bouncing. To export 16- and 24-bit tracks, simply bounce tracks twice, each time selecting the desired sample rate and bit-depth.
Quote from: Brian Skalinder on March 13, 2007, 11:20:20 PM
To export 16- and 24-bit tracks, simply bounce tracks twice, each time selecting the desired sample rate and bit-depth.
what exactly do you mean here?
would you simply export to Wav twice - and simply adjustthe settings to dither/resamp for 16bit?
also regarding stereo channels - it looks like you can process each channel individually by clicking on the L or R button underneath the scroll bar
Quote from: terrapinj on April 02, 2007, 02:00:57 PMwhat am i doing wrong here?
I'm guessing the two options you tried are probably using different SRC quality settings, hence the processing time difference. Two reasons that's my guess:
- my own testing of processing time using different SRC quality settings
- recollection reading on the Samplitude & Seqouia support forum (http://support.magix.net/boards/samplitude/index.php) that resampling manually via Offline Effects | Change Sample Rate or Export Sample or Track Bouncing (with Mixdown uses the same code.
FWIW, the
Track Bouncing method provides the greatest flexibility in defining SRC quality (High, Very High, Ultra High 1, Ultra High 2) v.
File | Export Audio (no option to select quality, dunno which it uses - based on the speed, I'd guess High)
Quote from: terrapinj on April 02, 2007, 02:00:57 PMbrian what is your work flow for a simple 24/48 > 16/44.1 conversion
I do everything in a virtual project (VIP), even 2-ch edits because the plain old WAV editor doesn't provide for object-oriented or non-destructive editing (at least as far as I can tell). Within the VIP, I use
Tools | Track Bouncing (internal Mixdown) and specify my SRC and dither options accordingly.
sweet - i'll try the track bouncing later tonight - wasn't sure if it was an actual function or a term you were using
FWIW - i double checked the md5 for the original file after using the Load Wav function as opposed to the virtual project and it still verifies fine.
Quote from: terrapinj on April 02, 2007, 04:28:52 PMFWIW - i double checked the md5 for the original file after using the Load Wav function as opposed to the virtual project and it still verifies fine.
Did you apply any edits, though? For example, in testing just now in the WAV Editor (not VIP), I apply normalization and save, SSE applies the edit directly to the WAV - overwriting the original. At any rate, I find using a VIP in all cases very flexible and maintains a consistent workflow / working environment. YMMV.
Quote from: terrapinj on April 02, 2007, 05:36:02 PMi never actually "Save" always save as or save some derivative or export in this case.
Gotcha. Additionally, one of the reasons I like the VIP is I can save my edits for future reference - no need to recreate the edits, remember what I changed, document what I changed, etc. It's all saved in the VIP so I may easily recreate my 24- and 16-bit final file sets, if needed.
Quote from: terrapinj on April 02, 2007, 05:36:02 PMunder the virtual project is it possible to alter the original file at all, even if you wanted to?
I've not tried explicitly to do so, but haven't seen any way to do it. Might be possible, dunno. But I'm glad it's not easy to do accidently. :)