Berkeley CSUA MOTD:Entry 37836
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/04/02 [General] UID:1000 Activity:popular
4/2     

2005/5/25-26 [Computer/SW/OS/OsX] UID:37836 Activity:kinda low
5/25    I recorded some family reel to reel onto my computer so that I could
        archive it digitally.  Unfortunately it was recorded at 1 7/8 in/min and
        I could only play it back at 3 1/4 in/min.  The AIFF file I have is
        therefore at double time.  Can't I just change the sampling rate and
        it will run normally?  If so, how would I do this in OS X?  -scottyg
        \_ Audacity has what I'm looking for.  Thanks -Scottyg
        \_ Most sample-rate converter programs are careful to preserve the
           pitch and duration and work by interpolation.  You could use
           an audio-editing package which offers speed and pitch control, or
           there may be some simple flags in AIFF you can change, but I
           wouldn't know about that.
           \_Yes, I'd like to just change the sampling rate, as recorded on the
             file itself.
             \_ Looking at http://www.borg.com/~jglatt/tech/aiff.htm
                It looks like starting at the 17th byte (data[16]) of the
                Common Chunk "COMM" there is
                an 80-bit, big-endian IEEE 754 floating-point number for the
                sample rate.  Good luck
                (As a hint, floating-point numbers can be divided by 2 by
                 subtracting 1 from the exponent)
        \_ Just curious.  What media records at 1 7/8 inch/minute?  That seems
           very slow mechanically to me.
           \_ Uhh...reel to reel, that's the slowest speed.
              \_ ITYM in/sec.
                \_Ooops..my bad. -scottyg
        \_ I think that 'Amazing Slow Downer' will probably do what you want:
           http://www.ronimusic.com/amsldox.htm
Cache (8192 bytes)
www.borg.com/~jglatt/tech/aiff.htm
Audio Interchange File Format (or AIFF) is a file format for storing digi tal audio (waveform) data. It supports a variety of bit resolutions, sam ple rates, and channels of audio. This format is very popular upon Apple platforms, and is widely used in professional programs that process dig ital audio waveforms. This format uses the Electronic Arts Interchange File Format method for s toring data in "chunks". pstring Pascal-style string, a one-byte count followed by that many text bytes. The total number of bytes in this data type should be even. A pad byte can be added to the end of the text to accomplish this. Constants Decimal values are referred to as a string of digits, for example 123, 0, 100 are all decimal numbers. Hexadecimal values are preceded by a 0x - eg, 0x0A, 0x1, 0x64. Data Organization All data is stored in Motorola 68000 (ie, big endian) format. The bytes o f multiple-byte values are stored with the high-order (ie, most signific ant) bytes first. The Sound D ata chunk, which contains the actual waveform data, is also required if the waveform data has a length greater than 0 (ie, there actually is wav eform data in the FORM) All other chunks are optional. Among the other optional chunks are ones which define markers, list instrument parameter s, store application-specific information, etc. All of these chunks are described in detail in the following sections of this document. All applications that use FORM AIFF must be able to read the 2 required c hunks and can choose to selectively ignore the optional chunks. A progra m that copies a FORM AIFF should copy all of the chunks in the FORM AIFF , even those it chooses not to interpret. There are no restrictions upon the order of the chunks within a FORM AIFF . Here is a graphical overview of an example, minimal AIFF file. It consist s of a single FORM AIFF containing the 2 required chunks, a Common Chunk and a Sound Data Chunk. A sample point is a value representing a sample of a sound at a given mom ent in time. Each sample point is stored as a linear, 2's-complement val ue which may be from 1 to 32 bits wide (as determined by the sampleSize field in the Common Chunk). For example, each sample point of an 8-bit w aveform would be an 8-bit byte (ie, a signed char). Because most CPU's read and write operations deal with 8-bit bytes, it wa s decided that a sample point should be rounded up to a size which is a multiple of 8 when stored in an AIFF. If your ADC produces a sample point from 1 to 8 bits wide, a sample point should be stored in an AIFF as an 8-bit byte (ie, signed char). If your ADC produces a sample point from 9 to 16 bits wide, a sa mple point should be stored in an AIFF as a 16-bit word (ie, signed shor t). If your ADC produces a sample point from 17 to 24 bits wide, a sampl e point should be stored in an AIFF as three bytes. If your ADC produces a sample point from 25 to 32 bits wide, a sample point should be stored in an AIFF as a 32-bit doubleword (ie, signed long). Furthermore, the data bits should be left-justified, with any remaining ( ie, pad) bits zeroed. For example, consider the case of a 12-bit sample point. It has 12 bits, so the sample point must be saved as a 16-bit wor d Those 12 bits should be left-justified so that they become bits 4 to 15 inclusive, and bits 0 to 3 should be set to zero. Shown below is how a 12-bit sample point with a value of binary 101000010111 is stored left -justified as two bytes (ie, a 16-bit word). Instead of storing all of the sample points for the left channel first, and then storing all of the sample points for th e right channel next, you "mix" the two channels' sample points together . You would store the first sample point of the left channel. Next, you would store the first sample point of the right channel. Next, you would store the second sample point of the left channel. Next, you would stor e the second sample point of the right channel, and so on, alternating b etween storing the next sample point of each channel. you store the next sample point of each of the channels in turn, so that the sample points that are meant to be "played " (ie, sent to a DAC) simultaneously are stored contiguously. The sample points that are meant to be "played" (ie, sent to a DAC) simul taneously are collectively called a sample frame. In the example of our stereo waveform, every two sample points makes up another sample frame. sample sample sample frame 0 frame 1 frame N | ch1 | ch2 | ch1 | ch2 | . For multichannel waveforms, you sh ould follow the conventions shown below for which order to store channel s within the sample frame. channels 1 2 | left | right | stereo | | | ||| 1 2 3 | left | right | center | 3 channel | | | | |||| 1 2 3 4 | front | front | rear | rear | quad | left | right | left | right | ||||| 1 2 3 4 | left | center | right | surround| 4 channel | | | | | ||||| 1 2 3 4 5 6 | left | left | center | right | right |surround | 6 channel | center | | | center | | | ||||||| The sample points within a sample frame are packed together; Likewise, the sample frames are packed toget her with no pad bytes. Common chunk The Common Chunk describes fundamental parameters of the waveform data su ch as sample rate, bit resolution, and how many channels of digital audi o are stored in the FORM AIFF. This does not include the 8 bytes used by ID and Size fields. For the Common Chunk, chunkSize should always 18 since there are no fields of variable length (but to maintain compatibility with possible future e xtensions, if the chunkSize is > 18, you should always treat those extra bytes as pad bytes). The numChannels field contains the number of audio channels for the sound . A value of 1 means monophonic sound, 2 means stereo, 4 means four chan nel sound, etc. For mul tichannel sounds, single sample points from each channel are interleaved . A set of interleaved sample points is called a sample frame. The actual waveform data is stored in another chunk, the Sound Data Chunk , which will be described later. The numSampleFrames field contains the number of sample frames. This is n ot necessarily the same as the number of bytes nor the number of sample points in the Sound Data Chunk (ie, it won't be unless you're dealing wi th a mono waveform). The total number of sample points in the file is nu mSampleFrames times numChannels. The sampleSize is the number of bits in each sample point. The sampleRate field is the sample rate at which the sound is to be playe d back in sample frames per second. One, and only one, Common Chunk is required in every FORM AIFF. Sound Data chunk The Sound Data Chunk contains the actual sample frames (ie, all channels of waveform data). chunkSize is the number of bytes in the chunk, not counting the 8 bytes used by ID and Size fields nor any possible pad by te needed to make the chunk an even size (ie, chunkSize is the number of remaining bytes in the chunk after the chunkSize field, not counting an y trailing pad byte). You can determine how many bytes of actual waveform data there is by subt racting 8 from the chunkSize. Remember that the number of sample frames, bit resolution, and other information is gotten from the Common Chunk. The offset field determines where the first sample frame in the WaveformD ata starts. Most applications won't use offset a nd should set it to zero. Use for a non-zero offset is explained in "Blo ck-Aligning Waveform Data". The blockSize is used in conjunction with offset for block-aligning wavef orm data. It contains the size in bytes of the blocks that waveform data is aligned to. As with offset, most applications won't use blockSize an d should set it to zero. More information on blockSize is in "Block-Alig ning Waveform Data". The WaveformData array contains the actual waveform data. The data is arr anged into what are called sample frames The number of sample frames in WaveformData is determined by the numSampleFrames field in the Common Ch unk. For more information, see "Sample Points and Sample Frames". The Sound Data Chunk is required unless the numSampleFrames field in the Common Chunk is zero. One, and only one, Sound Data Chunk may appear in a FORM AIFF. Block-...
Cache (723 bytes)
www.ronimusic.com/amsldox.htm
Amazing Slow Downer for Mac OS X Slows down the speed of the music - between -50% and 400% time-stretching without changing the pitch. Change the pitch in semi-tones - at full or lower speed. Adjust the pitch in cents (100ths of a semi-tone) to suit yo ur instrument. Real-time processing - all described above is done in real-time - just in sert the CD and press the play button! Also slows down MP3, AIFF, AAC/MP4 and wave files on your computer in rea l-time. Roni Music is a registered trademark and all Roni Music software are trademarks of Roni Music. Other names may be trademarks or registered trademarks of their respective companies. Prices, specifications, and availability are subje ct to change without notice.