use sample based measurements instead of wallclock time, and make sure that *you* get the math right.
the "inaccuracies" mentioned mostly concern compressed formats, not PCM data. On Mon, Feb 8, 2016 at 8:32 PM, Alexander Bollbach < [email protected]> wrote: > Perhaps this is a pedantic point but I've noticed that ExtAudioFileRead > does not read the amount of frames as requested. Now I know it states that > this may happen for technical reasons in the API documentation but I wonder > if this inaccuracy is noticed in audio software. For example, I created a > 10 second Mono/32bitFloat PCM wav recording in audacity. I create a buffer > to read the information onto and than write it onto a new ExtAudioFile. > When opening this new file in audacity the audio data is 16ms shy of 10 > seconds. (like i said, pedantic..). But I'm just curious if this is > accepted as normal behavior and if there is a way to do precise editing > using the ExtAudioFileRead/Write workflow. Is there a sample-perfect method > using non-realtime Core Audio tools? You can see the code I used to > generate the new audiofile from the old one on github > <https://github.com/AlexanderBollbach/CACreateFileWithContentsOfFile/blob/master/CoreAudio_CreateFileContentsOfFile/main.m> > . > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/coreaudio-api/paul%40linuxaudiosystems.com > > This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
