I use Audacity to record and edit my podcast. I wanted to add chapter markers, but that’s not supported. So I thought I’d do a “table of contents” instead - a list of labels with timestamps. I created a set of labels for the one-hour show and exported them. I then used a python script to clean it up a bit. But when I tested it out, the timestamps were off. Specifically, they get earlier. For example, if the label text file says it should be at 10:00 and I jump to that time, the audio at that point is before the audio where the label is in Audacity. However, the overall time of the audio file agreed with the overall time in Audacity - that is, the exported MP3 file wasn’t somehow time-skewed.
Is this a known bug? Or is it possible that I’m throwing this off somehow? If it matters, the export settings are “preset”, medium quality (145-185kbps), force export to mono.
Okay… so, thanks for the WAV suggestion. The problem actually seems to be with QuickTime player - it’s not finding the time spot when you scrub to the given timestamp when playing an MP3, but it does this fine with a WAV file. WAV files aren’t compressed, MP3 files are. My guess is that QuickTime Player isn’t handling the timestamp estimation properly with MP3s. If I import the MP3 file into Audacity, the timing is correct.
So… mystery solved. It’s not Audacity’s problem. Thanks @steve!
If I recall correctly, QuickTime player messes up the times for MP3s that have “Variable Bit Rate” (VBR encoded MP3). It’s not alone - several other players also have problems with VBR MP3, which is unfortunate as VBR encoded MP3 is generally better quality than an equivalent sized CBR (Constant Bit Rate) encoded MP3. This common bug is why Podcasts still tend to use CBR rather than (the better quality) VBR option.