Timestretching not perfect?

Hi

I am currently working on a studio mix where several already-finished-mp3-tracks are being mixed together. However the BPM of these tracks varies from maybe 128 to 132. My mix is at 130 (Sequencer set to 130). I am using the time & pitch machine to stretch these tracks to the correct speed. However the result isn't perfect (I always check it with the metronome and after a time it gets out of time). These tracks are made by proffesionnal producers (some of the biggest in electronic music) and they are at exactly 128, 130 or 132 BPM, it will never be something like 128,2. Why doesn't the time & pitch machine work correctly? Can this depend on the algorithm that is being used on the tracks (samples) ? I don't want my motivation to get lost so I'm trying to find out the problem as fast as I can!

Thank you

Revs

a) Time compression is never absolutely perfect. After all, time expansion/compression algorithms have to literally "invent" (expansion) or selectively and (hopefully) musically delete existing music (compression).

But that aside...

b) MP3's have inherent time drift. Regardless of what the original BPM of the tracks were, MP3's aren't going to play back with BPM perfection. That why they're rarely used for any kind of serious music production. So if you're looking to do any kind of time compression and get exacting results, you're going to need AIF or WAV files. Otherwise you'll be chasing your tail forever trying to get numbers to line up that won't ever line up.

c) there is no such thing as "exactly" any BPM. Every DAW's clock is going to vary ever so slightly from another's, so someone's track at 100 BPM done on (say) ProTools might end up syncing perfectly to a click in Logic at 100.0002.

So there are your problems. If you want to get a better handle on things, get AIFF or WAV copies of these files. And then you might find that you'll have to trade quality for exactitude in BPM.

b) MP3's have inherent time drift. Regardless of what the original BPM of the tracks were, MP3's aren't going to play back with BPM perfection. That why they're rarely used for any kind of serious music production. So if you're looking to do any kind of time compression and get exacting results, you're going to need AIF or WAV files. Otherwise you'll be chasing your tail forever trying to get numbers to line up that won't ever line up.

Hm, why exactly would an MP3 have any drift? I must admit I don't know this for a fact one way or the other, but my experiences (playing a WAV and an MP3 made from it side by side) and logic tell me that there's really no reason why an MP3 should play at a different speed than the original audio.

c) there is no such thing as "exactly" any BPM. Every DAW's clock is going to vary ever so slightly from another's, so someone's track at 100 BPM done on (say) ProTools might end up syncing perfectly to a click in Logic at 100.0002.

It's true that all digital clocks run at slightly different speeds. If you start playing the same song on two computers (or any music playback devices) at exactly the same time, they will get more and more out of sync over time.

However, there is such a thing as exact BPM, and if you use any modern DAW, stay completely in the digital domain, and sync everything to a single clock, your song _is_ going to be perfectly in sync with the "ideal" BPM.

Unless your DAW has some serious bugs in its audio engine, there will be absolutely no deviation from this ideal sync. A DAW doesn't have a "clock" that is locked to some value that might be slightly off from the "real" value. Bouncing a song (realtime or offline) is just a bunch of calculations, and there simply can't be any "drift" in that process. The concept of drift always requires two clock sources that run independently of each other. In theory, you could bounce your song using just pen and paper (and a lot of time...) if you knew all the required calculations, and the end result would still play perfectly at the desired tempo.

For example, a song with the BPM 120 and sample rate of 44.1 KHz will use exactly 22050 samples for each beat in the bounced audio file. This doesn't change, no matter if you are using Logic, Pro Tools, or any other software in the world. Unless the software in question has some strange built-in drift function, or some very odd bugs.

There _will_ be some drift from the ideal BPM if you play the song from your DAW, convert the audio to analog, and record it to another device (analog tape, DAT, etc). But even in this case, it's not the DAW itself that causes the drift. It's the difference between the clocks of your computer and the recording device.

a) Time compression is never absolutely perfect. After all, time expansion/compression algorithms have to literally "invent" (expansion) or selectively and (hopefully) musically delete existing music (compression).

True, I guess the only time stretching algos that can give you exactly the tempo you want are granular based, but those tend to sound horrible.

Time compression is never absolutely perfect.

You can say that twice.

b) MP3's have inherent time drift............

Hm, why exactly would an MP3 have any drift?

Data reduction.

I must admit I don't know this for a fact one way or the other...

So then experiment with it first and understand the behavior.

c) there is no such thing as "exactly" any BPM....

It's true that all digital clocks run at slightly different speeds.

Bingo. But then you go on to say...

However, there is such a thing as exact BPM, and if you use any modern DAW, stay completely in the digital domain, and sync everything to a single clock, your song _is_ going to be perfectly in sync with the "ideal" BPM.

There are a lot of "if's" in your last sentence. The day that everyone's running their DAW clocked to a singular (and hopefully accurate) word clock source, there will never be "exact" BPM. Can we all be very reasonably close to working at the same BPM or clock speed when setting our respective DAWs to, say, 128 BPM at 44.1K not sync'd to word clock? Yes. But will they be exactly the same? Nope. Never.

Final word: working in the digital domain does not ensure mathematical precision or timing or sound. The term "Digital domain" carries with it many meanings and applications. A 16-bit dithered version of a 24-bit audio file will never have the same dynamic range. "But it was converted in the digital domain!!" Yes, true, but not without inherent changes to the nature of the recording.

An MP3 of that 24-bit file encoded at 256 or higher might be fairly indistinguishable sonically from the 24-bit file, but it won't have all of the dynamic range AND it will drift here and there in speed.

And so on and so on...

Though OT, I'll throw one more thing on the pile...

Sample rate conversion doesn't result in a file that's the same length as the original. Take, say, a 44.1K file and SRC it to 48K. Or vice versa. Then compare the length of the files (in samples, of course) and you'll find that they're not the same length.

ski wrote:

Time compression is never absolutely perfect.

 

You can say that twice.

I'll say it twice but differently...

Digital conversion of stuff is never absolutely perfect.

So anyway, getting back to the topic at hand, I stand by what I said in my original post. And what I wrote is based on facts and lots of experience. We could continue to have a detailed discussion about how these kinds of discrepancies manifest themselves in digital gear, but that should be another thread.

b) MP3's have inherent time drift............

Hm, why exactly would an MP3 have any drift?

Data reduction.

An MP3 of that 24-bit file encoded at 256 or higher might be fairly indistinguishable sonically from the 24-bit file, but it won't have all of the dynamic range AND it will drift here and there in speed.

Hm, I'm not sure if we are talking about the same thing when we talk about drift. My definition of it is that something gets more and more out of sync over time. On the other hand, two things can go slightly out of sync temporarily, and still stay in perfect sync overall. I consider that a different concept from drift, where the effect is cumulative rather than temporary. When you say a file will drift "here and there", what exactly do you mean?

So then experiment with it first and understand the behavior.

I did, and like I said, I put an MP3 and the original WAV side by side in Logic. While most single sample values differ slightly between the two (as expected), there's no real drift between them, meaning they don't get more and more out of sync over time. There are of course local differences here and there, but even with a ridiculously low bitrate, it's still very easy to see a sample-accurate sync between the original audio and MP3 after several minutes into the song.

The day that everyone's running their DAW clocked to a singular (and hopefully accurate) word clock source, there will never be "exact" BPM. Can we all be very reasonably close to working at the same BPM or clock speed when setting our respective DAWs to, say, 128 BPM at 44.1K not sync'd to word clock? Yes. But will they be exactly the same? Nope. Never.

I think we might be talking about slightly different things. I'll try to explain myself clearly enough, I really don't mean to cause any trouble.

When you press play in Logic and hear a song from the speakers, it's always playing at a slightly random speed. The "perfect" BPM can't exist in any realtime playing of digital audio, because it's ultimately synced to your computer's clock source, which always varies a bit and changes from computer to computer. Right.

However, inside a bounced audio file, a perfect BPM can (and will) exist. Just set Logic to 120BPM, and play a bass drum on each beat for a couple of minutes. Bounce the project, and add the audio file to arrange. It's in perfect sync, no matter how long the audio file is. You can do the same in Pro Tools (or any DAW), bounce the file, move it to Logic, bounce it again, move back to Pro Tools, and so on. The audio will stay in perfect sync, no matter how long you keep doing this.

The only thing that matters here is the samples per beat ratio, which does not change, because it does not depend on any external clock. If the sample rate of your project is 44100 and your BPM is 120, every DAW in every computer will use exactly 22050 samples for every beat in the bounced file.

If you can use offline bounce in Logic (meaning you don't use any external gear), it clearly shows that there's no need to "sync" the bounce process to anything. It's a series of calculations, which you can perform at any speed, and the operation does not need a word clock or any clock source for anything. You only need to know the current sample rate and tempo. Even a Commodore 64 could do the calculations, and your song would still sound the same.

The deviation/drift/imperfection is only introduced at the moment you play the song through a D/A converter. If you want to capture that drift, you need to record the song again with another device, that uses an independent clock (if you record digitally with the recording device synced to the playback device, the drift is lost and the recording will be in 100% perfect sync). But even with the drift happening, your DAW and computer is still producing an exact and steady amount of samples per beat. That ratio does not change, even though both numbers can slightly deviate in the analog world.

Final word: working in the digital domain does not ensure mathematical precision or timing or sound. The term "Digital domain" carries with it many meanings and applications.

Yes, very true. Thus, lots of ifs.

I have to say that this is a very interesting topic from a theoretical point of view, but speaking from a purely practical perspective - and I'll admit that I don't really know anything about the mathematics - I wonder how relevant the issues are.

I occasionally use some virtual synths and a sampler which were never ported to OSX (the old Koblo Studio stuff - I really like their sound) inside Cubase VST on an old computer I keep specifically for this purpose. I set Cubase to the same tempo I'm using in Logic, bounce and then import the audio files into Logic. I've never had any tempo problems doing this.

I also export some of my old Cubase VST songs to MIDI files, import into Logic, then import the original audio files into Logic, again without any tempo issues.

I can't contribute anything specifically to issues that Rev is dealing with - I never use mp3 files in music production - but from my experience there is no noticeable variation in tempo between DAWS or even operating systems. If there are differences, then for all intents, they are so minute as to not matter.

Cap'n, no trouble here, though initially I wasn't sure if you thought I was pulling this info out of my derriere or if you wanted to have a discussion.

On the subject of MP3's, there isn't a single engineer I work with who has ever thought to (or actually gone so far as to) provide MP3's for production. MP3's for refs? Sure. Production? Never. And the reason isn't even so much of fidelity (because high bit rate MP3's can sound pretty darn good). The problem is sync. I can't imagine that everyone I work with (including me) is under a false impression that an MP3 has all the sonic and timing integrity of original-source AIFF's and WAV's. Think about it... PCM audio has one sample per clock. Can't say that for MP3's... And maybe that's the easiest way to explain it.

Clocking... reddog is right, that the sync discrepancies that can occur between systems are usually so slight as to be unnoticeable. However, people throw good money at buying wordclock generators for single computer audio systems. So the question to ask is "why?"

Other than that, like I said, I stand by what I wrote in my original post, not to be stubborn but because I know it to be fact.

Remember: All theories are good, in theory™

Regards,

-=sKi=-

Cap'n, no trouble here, though initially I wasn't sure if you thought I was pulling this info out of my derriere or if you wanted to have a discussion.

Heh, of course I'm only trying to make some civilized discussion here. I'm very interested in audio from the technical point of view, and want to get to the bottom of everything, nothing bad in that I suppose. I'm all for the scientific method - I start with the assumption that I know nothing, then I start experimenting, then see what happens, and in the end hope I'm a little wiser.

The beauty of digital audio is that there really isn't any room for opinions. We all have the tools to see if something "is" or "isn't", and below the level of single samples and bits, there is nothing, no magic. I'm simply interested in finding the truth (whatever that might be) using the tools and senses I have. If I'm wrong, I'm very happy to admit that, but I need very solid evidence to convince me I'm wrong, and I want to fully understand why I'm wrong, and what is the correct answer.

On the subject of MP3's, there isn't a single engineer I work with who has ever thought to (or actually gone so far as to) provide MP3's for production. MP3's for refs? Sure. Production? Never. And the reason isn't even so much of fidelity (because high bit rate MP3's can sound pretty darn good). The problem is sync. I can't imagine that everyone I work with (including me) is under a false impression that an MP3 has all the sonic and timing integrity of original-source AIFF's and WAV's. Think about it... PCM audio has one sample per clock. Can't say that for MP3's... And maybe that's the easiest way to explain it

Whether MP3's can be used for production and if they have the same sonic quality (frequency response etc) than the original wasn't really the issue here, this was only about timing and sync. Of course MP3s have lost lots of data and they sound inferior compared to the uncompressed audio and no-one should use them for any production work, but all that is beside the point.

There is no mathematical reason why an MP3 that has lost data _must_ also be out of sync, time-wise. You can easily do all kinds of nasty stuff to audio, mangle it in every possible way, reduce the quality etc, and still not change the overall timing one bit.

But again, as per scientific method, we don't need to know what causes something in order to examine the effect. I tried to find this drift myself, and couldn't. In my tests, MP3s and WAVs stay in sync at sample level, even if the MP3 has a very low bitrate. If you or someone knows how to observe the drift in MP3s, just show me an example, and I'll stand corrected.

Clocking... reddog is right, that the sync discrepancies that can occur between systems are usually so slight as to be unnoticeable. However, people throw good money at buying wordclock generators for single computer audio systems. So the question to ask is "why?"

A good clock source is of course relevant if you for example record your songs to an analog tape recorder. But if you do everything inside a single computer using nothing but software, you simply don't need any wordclock generators. Your DAW understands perfectly well that 120BPM at 44kHz means 22050 samples per beat, no matter what the clock source.

But let's think this whole thing in another way. Ultimately we are producing digital audio files, where one sample is the smallest unit of time. For two audio files to be out of sync with each other, they need to deviate by one sample or more. If their samples do have a 1:1 correspondence all the way through, then they are in perfect sync, and there's nothing more to it.

At a sample rate of 44100 and BPM of 120 and the assumption that everything is perfect, each beat will consist of 22050 samples (120BPM = 2 beats per second, there are 44100 samples per second, so each beat = 44100/2 = 22050 samples). I think everyone in the world can agree with that, no?

Let's say different DAWs run at slightly different speeds, and have varying concepts of tempo. Maybe 120BPM in Logic is something slightly different in Pro Tools. What this means in practice is that when Logic bounces an audio file, it will actually produce slightly different amount of samples per beat than the ideal 22050. Maybe 22047? And since Pro Tools has a different understanding of the same tempo, maybe its bounce will have 22055 samples per beat.

This is the only way that alleged timing differences between DAWs can manifest themselves. It means that bounced files actually have a different amount of samples per each beat. Now if this really is the case... it's really easy to check. Just bounce something in Logic, and add the audio file to arrange (or Pro Tools, if you want to).

Does the bounced file align perfectly with the bars and beats in Logic or PT? If it does, Logic just bounced a file with perfect sync, and our assumption that DAWs somehow run at "non-perfect" speeds is simply wrong.

To the OP:

Try re-pitching the tracks using flex time in pitch mode (you can also do this using Classic mode in Time&Pitch Machine but it is more work). This is the same as speeding up or slowing down a turntable and as there is no time stretching you should get less artifacts and a better result.

"Clocking... reddog is right, that the sync discrepancies that can occur between systems are usually so slight as to be unnoticeable. However, people throw good money at buying wordclock generators for single computer audio systems. So the question to ask is "why?""

Yes, involver's solution is what I would use in the OP's case as well.

Darn! And I thought this post was hi-jacked by ski and captain, hihi.

Because what you really need for clocking is this puppy, which I kept around since 25 years:

Now we're talking ultimate clocking and synchronization. Please note that SRC on this device stands for: "SMPTE Reading Clock", and not Sample Rate Conversion. This beautiful beast keeps my 808, PPGs and Synclavier happily in sync with Logic. It even synchronizes my microwave. Seriously. And: it jitters with any mp3 or live performance thrown at it!

Yes, ski, I know exactly what you meant with the mp3 "drift". You should have called it "jitter" instead. What captain described is drift.

Happy jittering Saturday to all!

[image too wide removed by moderator - Please keep all screenshots below 800 pixels, thanks. Read Me Before Posting - Forum Guidelines (#8 )]

Think about it... PCM audio has one sample per clock. Can't say that for MP3's... And maybe that's the easiest way to explain it.

I'm very interested in this subject about MP3 timing drift - I've not heard of exactly that before... As I understand it, this is happens during MP3 compression:

1. Take a chunk of samples (ok, looked it up; it's 1152 samples)

2. Separate it into a bunch of frequency bands using crossover-like splits

3. Do a Fourier transform on each band-limited section

4. Judge which frequencies won't be audible in that moment, and throw them out

5. Losslessly encode the (now simpler) data (still in the frequency domain)

6. Repeat with next chunk of samples

Which means that an MP3 can't be an arbitrary number of samples long (witness the headaches with MP3 gapless playback), and I can imagine individual transients maybe being shifted a tiny bit... but what could cause the entire file to drift if it's broken down into 1152-sample chunks and then reconstructed? No samples (time domain) are thrown out as far as I know, and if so, the file really should stay perfectly in sync. Does anyone know any more info about this or examples? I'm very curious to get to the bottom of this.

I did the following test: I made a test WAV with over 30 minutes of audio, including some modern rock, white noise (the most difficult sound for MP3 compression), and silence. I then encoded four MP3s out of it, using Logic's own encoder and a freeware LAME encoder, both with a high (320kbps) and low (96kbps) bitrate. Then I put the WAV and the MP3s side by side in Logic, and compared them graphically (and listened too!).

The first observation was that the files encoded with LAME had some extra space in the beginning, for whatever reason. That was easily fixed though, I just trimmed the beginning a little.

But the big question - are the files in sync with each other after 30 minutes, using several different MP3 encodings? The answer is yes, not even one sample difference. Here's a picture if you don't believe me:

http://www.insomniac-music.com/stuff/logic_mp3_sync_test.jpg

You can see how the waveforms differ slightly from each other, it's visible even here. But at the same time, they are in perfect sync. The same applies to all other parts of the files I checked.

OK, there's my experiment, now is everyone's chance to prove me wrong with contradicting test results!

Hello Sonther!!! We'll have to catch up.

Meanwhile, based on some of the info presented here, what's the conclusion? Can we dispense with the use of AIFF and WAV files now? Come to think of it, they've always been pesky damn things. They take up so much space, and sooooooo hard to email...

This subject is indeed interesting but I'm just not going to get into it any further. Too many absolutes being thrown around about how things supposedly work. I'll just stick with my own "absolute" of not dealing with MP3's for serious audio production. And I'll also stick with what I said in my initial post.

Debate away!

Regards to All...

I think the original poster had some other problem with the timing. With the exception of VBR stuff I think MP3s should line up OK, especially with short loops.

As for MP3 use, argh, I prefer original material if possible. It's best to start from the best possible quality and go down than start with already degraded audio that will be worse after all the possible trans-codings an audio product will go through.

With the exception of VBR stuff I think MP3s should line up OK, especially with short loops.

Ah, totally forgot to test VBR. I bounced a couple of test files in Logic using VBR encoding. Same results, perfect sample accurate sync.

With the exception of VBR stuff I think MP3s should line up OK, especially with short loops.

Ah, totally forgot to test VBR. I bounced a couple of test files in Logic using VBR encoding. Same results, perfect sample accurate sync.

OK, sounds VBR works fine, then. Some audio players, long time ago, had problems with sync and VBR. Maybe all this is taken care by Logic converting the MP3 to a WAV underneath and taking care of the timeline mapping.

Wow this has become huge haha!

Well, the problem is that I can not always use WAV's, as they're not always available. Most digital releases are in MP3 these days (I'm talking about electronic dance music).

But it looks like nothing gets out of sync anyway

I will explain my problem once again: I am working on a studio mix. With "mix" I don't mean what you probably understand under mix, but what a DJ does. A DJ mix is when one song is played after another and transitions between them are made. On the turntables, the DJs 'sync' (beatmatch) the tracks and that's how they mix one song in another. But this time I am doing a studio mix, a studio mix is when such a mix is done with software. There's plenty of studio mixes out there, actually every album, compilation or promo mix is done on software and not on turntables. For perfection. But apparently it doesn't work for me. I am using Logic 8, which is set to 130 BPM. My first song was at 128 BPM. I stretched it to 130. Everything went fine. The next song is already at 130 so I leave it. I put the first beat on a bar and go over it with the metronome to check if it's really in time. And there's already the first problem - it isn't. Altough Logic says it is 130 BPM and I know it is. But it seems like it's not, it seems like it's 130,001 BPM. The first question would be, how can I find the exact BPM of a track?

Right, and then the next problem. A song is at 126 BPM. I stretch it to 130. But it's not exactly 130. I checked before (when it was 126) if it was really 126 and not 126,001 or something, and yes it was really 126. That would mean Logic's time and pitch machine doesn't work properly. Or not exactly. A friend who uses Fruity Loops told me he never had such a problem. And actually I already did mixes like that in the past and didn't have problems aswell, however I used another algorithm and I was wondering if this could eventually sometimes affect this. I am using another algorithm now because of the quality, the last one I used (when it worked) made the songs sound strange!

Maybe it's more clear now

Revs

But this time I am doing a studio mix, a studio mix is when such a mix is done with software. There's plenty of studio mixes out there, actually every album, compilation or promo mix is done on software and not on turntables. For perfection. But apparently it doesn't work for me. I am using Logic 8, which is set to 130 BPM. My first song was at 128 BPM. I stretched it to 130. Everything went fine. The next song is already at 130 so I leave it. I put the first beat on a bar and go over it with the metronome to check if it's really in time. And there's already the first problem - it isn't. Altough Logic says it is 130 BPM and I know it is. But it seems like it's not, it seems like it's 130,001 BPM. The first question would be, how can I find the exact BPM of a track?

Yeah, I have done something similar back in the day, trying to beatmatch different songs is actually a nice little challenge.

The basic problem is that when you get random songs from various sources, you don't know how the songs have been produced and what they have been through. For example, a song might have been on analog tape at some point during its life. This means the tempo can be literally anything, it doesn't have to be a nice exact integer. It's also possible the tempo varies slightly during the song, so finding a single tempo that works for the whole song might not be even possible. And on top of that, single notes might also miss their "correct" place slightly, which is guaranteed if the song has been produced using a traditional MIDI setup.

But if we start with the assumption that we can find a single tempo that works well enough for the whole song, you could first just align the 1st beat of the 1st bar of the song with the same position in Logic. Then use Logic's click to find an approximate tempo first, then zoom in to the the end of the song, and fine tune the tempo until it looks like the beat syncs nicely with the grid. I guess you are working with songs that have a steady 4/4 beat going, and that makes this task a lot easier. (But that's what you already did...?)

Another possibility is to try the "adjust tempo by selection & locators" in sample editor, you just have to be extra careful to get the selection & locators right.

Right, and then the next problem. A song is at 126 BPM. I stretch it to 130. But it's not exactly 130. I checked before (when it was 126) if it was really 126 and not 126,001 or something, and yes it was really 126. That would mean Logic's time and pitch machine doesn't work properly. Or not exactly. A friend who uses Fruity Loops told me he never had such a problem. And actually I already did mixes like that in the past and didn't have problems aswell, however I used another algorithm and I was wondering if this could eventually sometimes affect this. I am using another algorithm now because of the quality, the last one I used (when it worked) made the songs sound strange!

As someone said, time stretching audio is usually a pretty complex process, and unless the algorithm you are using is designed for that purpose, it could be that achieving the exact tempo or length you want is impossible.

If you only need to adjust the tempo by a small amount, simply pitching the song a little could be the best option. And I definitely recommend trying flex, which can help even if a song has a slightly drifting tempo. (8 didn't have flex, right...? so you need to update to 9 first).

This might be your best bet...

http://www.native-instruments.com/#/en/products/dj/traktor-pro/

But if you want to stick with Logic for this...

To find out the exact tempo of a track according to Logic, open each song in a new project. Use beat mapping to find the BPM. It's really easy:

• lay up the song at bar 1

• trim the top of it to ensure that the track starts with a beat (no acapella intros, etc.)

• beat map the first few beats and see if the metronome lines up by playing the track for a few more measures. If the click is good...

• spot-check playback the rest of the track to see if the click remains reasonably in time over the course of the track. If it does, draw a beat map line on the very last beat in the track

• erase all of the beat mapping lines except for the first and the last

• look in the tempo window or the transport at the BPM. THAT is the BPM of the track. Confirm by spot-checking playback again with the click.

I would venture a guess that any track which you use this method for identifying the BPM will result in a fractional BPM value. Even a track originally produced in Logic.

I would also suggest that you get over the idea that any of the tracks that you're going mix are at a "perfect" (non-fractional) tempo. If you insist that there is such a thing as "perfect" BPM -- especially when you're timestretching stuff -- you're only doing yourself a disservice because you're simply banging your head against the wall working on false assumptions. (After a while it's gonna start to just plain hurt. ) Just because a track is produced professionally (as you said in your first post) doesn't imply that the tempo of the track you're working with is going to result in a perfect BPM count. "Professionally produced" and "non-fractional BPM" have absolutely nothing to do with one another.

So really, I'm not trying to be difficult by telling you this. I'm actually trying to help you out by letting you know the real deal.

I would venture a guess that any track which you use this method for identifying the BPM will result in a fractional BPM value. Even a track originally produced in Logic.

Even at the risk of repeating myself (I must be careful since you are a moderator ), I'll just say again that a perfect tempo is very well possible, and in fact every song that is produced & bounced with any modern DAW, and not gone through any analog stages, will play perfectly at the correct tempo.

I know you are sick of the subject don't want to believe me, no matter what hard evidence I present, but I very sincerely ask you to simply try it for yourself.

You have Logic (and I guess Pro Tools?), and you probably have a couple of minutes of extra time at some point. Open Logic, and bounce X bars of whatever material you wish at 120BPM and 44100Hz. Now add the bounced file back to Logic.

If Logic didn't stay perfectly in correct tempo, the length of the file should be slightly different than the ideal, which is the number of bars * 2 * 44100 samples. Open the file in sample editor, choose view -> samples, select all, and check the number in the upper right corner that shows the length of the selection. Does it differ from the "perfect" value? You can also do the same in Pro Tools, or any DAW.

You don't have to be careful with me because I'm a moderator. You're not gonna get banned or nuthin' just because we disagree here. All I look for is accurate information. You've listed a lot of theoretical reasons why things should be the way you think they should be. But things don't always work out all nice and neat as you'd like them to, even in the digital domain.

I don't believe that the OP is going to be well-served by fostering his expectations of perfect time-compression and perfect BPM. With respect to the latter, it's just numbers. Not a single person dancing to a mix of tracks playing back at 130 or 130.0001 is going to know or care what the actual tempo is, or whether they're moving to a timestretched track that's .0001 BPM faster than the ideal numerical tempo of 130.000

Would you think David Morales or any of the big DJ's cares if the tempo of a track that they're matching up results in a fractional BPM? Trust me, David doesn't get out his BPM microscope and ponder, "Hmmm... this track is playing one ten-thousandths of a BPM faster than I'd like. Maybe I won't play it after all."

So to get back to the original topic, and at the risk and annoyance of repeating myself, "no, timestretching is not perfect".

You don't have to be careful with me because I'm a moderator. You're not gonna get banned or nuthin' just because we disagree here. All I look for is accurate information. You've listed a lot of theoretical reasons why things should be the way you think they should be. But things don't always work out all nice and neat as you'd like them to, even in the digital domain.

Yeah... all true. But I don't know how I could be more accurate than I have been? During this thread, I have made several tests and calculations with real software and real data, and observed what happens in them. I have explained how modern DAWs bounce audio and handle tempo and sample rate. I have told how everyone can test these same things themselves, and prepared to adjust my facts as soon as someone shows me contradicting evidence. When you bounce some audio files and compare them sample by sample, there's nothing theoretical about that. That's as real life as it can be.

I am half programmer and half musician, so I really want to get down to the bit level and see what happens there. I know that even in the digital domain, strange things happen. But the cool thing is that opinions don't matter here. No matter what I say or everyone else says, 1+1 is and will be 2. Or, for example, if two audio files cancel each other perfectly in a null test, then they contain identical audio. There's no magic between the bits.

Similarly, if Logic bounces time after time a file that has exactly the length it is supposed to have at the current tempo, we have no other choice than to conclude that Logic plays exactly at the correct tempo. Or?

So to get back to the original topic, and at the risk and annoyance of repeating myself, "no, timestretching is not perfect".

Yes, I don't think anyone ever disagreed about that. We have talked about several different and isolated things in this thread, and it would be great if we could keep and handle them separately, because they don't necessarily have anything to do with each other. To recap, and everyone feel free to correct me (with some hard data) if I'm wrong:

You should not use MP3s for any serious work. MP3 is a lossy compression format, and it never sounds as good as the original.

In my tests, I couldn't find any tempo drifting or other sync issues with MP3s. But of course you still shouldn't use them for serious work because of all the other sonic problems.

Depending on the algorithm you use, time stretching will most probably not give you exactly the tempo you are looking for.

A random song X from source Y probably isn't going to play exactly at a nice integer BPM. That's because a million different things may have changed the song's tempo, and you have no idea what they are.

However, a modern DAW, set to tempo X, will bounce a song that plays exactly at tempo X. That's because when a modern DAW is bouncing a song, it's not like there's a module that "plays the song" and another module that "records the song" inside your computer. Instead, your DAW sees the song as a long list of calculations, which will produce the same exact results every time. Bouncing the song is simply making these calculations, and writing the answers to the bounced audio file.

If it still is difficult to believe this, it might be a good idea to recall the good old Csound: you write sort of a computer program, in which you describe a song, including all its sounds, tempo, notes, etc. Sort of like a non-realtime hardcore composing environment. After writing the program, you run it, your computer does lots of calculations, and finally renders the end result to an audio file.

It's probably quite easy to accept that Csound does not and can not have any kind of "drift". If your song has tempo X and sample rate Y, Csound will just use them as variables in its calculations, and render the sound file accordingly. After all, any computer program that does not have any random variables will produce the exact same output, every time, on every computer.

Now, in essence, every modern DAW works like Csound, just in realtime. Or actually, offline bounce is exactly like Csound.

@ Ski: Traktor is for live mixing, what I am doing isn't live! Haha I have 6 decks for live mixing so I don't really need this!

OMG! 6?!?

I know that David uses Traktor to make his radio mixes and to listen to stuff when he's traveling. And based on that impression I thought it could be used non-live.

I am aware of the fact that there is no perfect BPM then...

...and yeah people won't notice that a track is 0,001 BPM faster but it's more like 0,1 since the tracks get out of time and you DO notice that!

Of course, .1 is a different story.

So I am wondering, what is the solution for this? How do all the albums get mixed? There MUST be a solution because so many people are doing it!

Let me ask... when you mix two songs, what's the longest you'd ever run "Song A" into "Song B"?

@ Cap'n What exactly do you mean with I get these tracks from various sources? I bought them digitally on various websites, so they should be perfect, none of them are vinyl rips or ripped off youtube (which would explain the BPM thing)

Yup, but what if the producer of the song wanted to give it some analog vibe, recorded it to an old tape recorder, then sampled back to DAW? Even mastering a song with analog equipment could make it go slightly out of sync. Just a couple of examples - the point is that you can do all sorts of things to a song, and even if you buy it as an MP3 from the net, doesn't guarantee anything. And heck, who knows, maybe the producer of the song set the original tempo to 130.00001 on purpose, just to give people a hard time?

No Logic 8 doesn't have that, and my system doesn't support 9 I think, will have to check... But I think my computer hasn't got enough power anyway!

Flex doesn't really need much CPU, if you are worried about that. And if you have any songs that have a slightly drifting tempo, it's really your only option (if you insist on using Logic )

I think someone clicked Edit instead of Reply there

@ Ski: Well not really 6, I had 4 turntables but later replaced two of them by CDJ's. I still have the turntables but don't use them anymore, no space and the mixer has only 4 channels

Yes of course it can be used non-live but what I ment with "live" was "real-time". So let's say if I was doing a 1-hour mix now I'd have to spend one hour with traktor, I cannot stop and continue later. Also there are many things that you cannot do with traktor, I modify a lot of the songs that I mix in Logic.

It all depends how it is mixed, but most of the time (in a normal mix) song A will run into song B for maybe 1-2 minutes. Or less! Just for the transitions. But what I'm doing is a megamix/mashup mix, that is much more complicated and all the tracks are mashups, so there is at least always 2 tracks running into each other all the time, so let's say song A and song B are running together, creating a single track, song C and D are now coming (both considered as a single track aswell) and are mixed together with A and B. See what I mean?

@ Cap: Hmm that would be possible of course but that sounds strange to me - House and Techno are always very exactly. Otherwise DJ's couldn't mix those tracks live! But yeah I already had the thing with 130,0001 on purpose in my mind haha!

Hmm yes I've just read something about Flex... sounds good.. but I'll have to change my computer first, mine is running 10.4 and it's a PPC, Logic 9 is only for 10.5.7 I think with an intel processor. I'm thinking to buy the 27" iMac soon enough, when I have enough money

How many CPU clock cycles fit in one sample at 44.100 Hz? That number is your possible measuring error at "sample accuracy".

@2.66 GHz

2,660,000/44.1 (KHz) = 60317

Anyhoo, the MAIN problem with using encoded audio directly is that the audio engine/CPU has to decode it in realtime, putting extra strain on the CPU, probably also enhancing the chance of all sorts of errors. Converting them to PCM (AIFF, WAV, SDII) will at least eliminate any problems arising with the "stress" of realtime decoding, that is the main reason for me to not use encoded audio.