Ableton Forum

i dont believe it.

its fuckin quicktime - is there no end to the evil.

as so as i loaded quicktime all the files are back to normal. i cant believe its not made common knowledge. i cant be anything else. it the only new thing i've done.

nuperspective wrote:i dont believe it.

its fuckin quicktime - is there no end to the evil.

as so as i loaded quicktime all the files are back to normal. i cant believe its not made common knowledge. i cant be anything else. it the only new thing i've done.

wow.
.

the decoding cache for the same track on each computer was a different length. install quicktime and it recognises the asd files.

to prove. i installed quicktime. i pulled in one file that was already in the decoding cache before the install. the asd files didnt work. pulled in some other files that are new the decoding cache [that i had tested before] completely fine. so i deleted all files in the decoding cache. pulled in the original file. everything fine.

i cant understand why that would be the case. it seems a blinding oversight on the part of ableton not to incorporate their own bespoke wav convertor. at least state on the documentation that ableton prefer quicktime to be installed. quality control has gone right out the window on this one.

no wonder people are having issues.

Hi Nuperspective,

thank you for finding the reason for this problem.

We had some asd issues earlier when users switched from live 4 to 5,
which were related to problems with different date settings on their
computers, so files appeared to be in the future and such.
We resolved the problems as much as we understood them,
but still some cases remained which could not be reproduced here.

There was no hint so far, that the problem effected only mp3 files.
Was that the case for you? This changes everything.
In the Live5 manual we recommend using QuickTime
for VBR files, but didn't know that it helps with the asd files.

Just last week, another user, bragi0, experimented with non-standard
DirectShow decoders and found that they produce different output
(which means the don't conform to the MPEG2 standard).
See http://www.ableton.com/forum/viewtopic.php?p=221177.

Nuperspective, would you be willing to help me to reproduce and
fix the problem, if possible, or to find a better workaround?
This would be great.

Please let me know, by mail, or a personal message, then I'll
send you instructions how to obtain more information.

Yours,
Ralf

I don't know if this will help the problem you describe but I have had a similar problem in the past and when I really looked hard at the files I noticed that all of the files which were having their warp data rewritten from scratch by live had somehow gotten their Date Modified and Date Created parameters later in time than the same parameters on the analysis file - as if the analysis files were created before the actual audio!

I managed to transfer the audio files from one computer to another which I changed the date on and made pretend edits using an audio editor to update the files. When I transferred them back the original warp markers all worked again - a massive hassle but not as bad as redoing the markers.

Suade wrote:I don't know if this will help the problem you describe but I have had a similar problem in the past and when I really looked hard at the files I noticed that all of the files which were having their warp data rewritten from scratch by live had somehow gotten their Date Modified and Date Created parameters later in time than the same parameters on the analysis file - as if the analysis files were created before the actual audio!

I managed to transfer the audio files from one computer to another which I changed the date on and made pretend edits using an audio editor to update the files. When I transferred them back the original warp markers all worked again - a massive hassle but not as bad as redoing the markers.

Now you mention it I had a similar issue.

On OSX you can just use the terminal and go to the directroy where the wavs and asds are and type "touch *asd". I don't know how to do it on windows.

Suade, Robin,

yes, that's the intended behavior since Live 1.5 or so:
if the asd file is older than the audio file, then
we assume that the audio file has changed and don't
use tha asd file. Normally that's what you want.

To touch files on Windows, I'm using cygwin (which is cool anyway).

Yours,
Ralf

Ralf wrote:Hi Nuperspective,

thank you for finding the reason for this problem.

We had some asd issues earlier when users switched from live 4 to 5,
which were related to problems with different date settings on their
computers, so files appeared to be in the future and such.
We resolved the problems as much as we understood them,
but still some cases remained which could not be reproduced here.

There was no hint so far, that the problem effected only mp3 files.
Was that the case for you? This changes everything.
In the Live5 manual we recommend using QuickTime
for VBR files, but didn't know that it helps with the asd files.

Just last week, another user, bragi0, experimented with non-standard
DirectShow decoders and found that they produce different output
(which means the don't conform to the MPEG2 standard).
See http://www.ableton.com/forum/viewtopic.php?p=221177.

Nuperspective, would you be willing to help me to reproduce and
fix the problem, if possible, or to find a better workaround?
This would be great.

Please let me know, by mail, or a personal message, then I'll
send you instructions how to obtain more information.

Yours,
Ralf

Hi Ralph, I´m not sure if the problem Quicktime resolved here is the same as you described in your post. Isn´t it the difference in the filelenght that makes loose the warpmarkers, as when you replace a sample with one wich has a different lenght in clip view?
However, you and bragi0 talk from offset markers here and in the encoder thread, couldn´t this have something to do with the moving markers bug?

http://www.ableton.com/forum/viewtopic. ... highlight=

http://www.ableton.com/forum/viewtopic. ... highlight=

http://www.ableton.com/forum/viewtopic. ... highlight=

So there are a few people for the moment wich have this problem, mostly with recently purchased 320 kB stuff as it seems from beatport and trackitdown only. I could email them and ask wich encoder they use, perhaps this could help to nail it down, as there is not a word from ableton until now, not even " sorry, but we have no idea or we can´t reproduce" .

Greetings

Steve,

thanks for the pointers. Usually, silence means "we have no idea
or couldn't reproduce it", but this time I didn't scan the forum for a while,
and the problem didn't reach me, and I was not aware that it gets worse
with people using higher bitrate formats, vbr, and non-standard decoders.
I'm sorry for the delay.

Live assumes that the output of the decoders is reliable, as the standard
requires. Breaking this rule explains the described effects, including the
jumping markers when zooming in (the waveform jumps, to be precise).

The next step for me is a further analysis of the decoders behavior, so we
at least come to a recommendation what decoders to use, how to find out
about them, installation, etc.

So please, everybody who has this problem, could you please get in contact
with me so we can find out, what decoders you are using on the
different machines. Thanks alot!

Yours,
Ralf

PS. Concerning a use of the decoded Wav/Aiff files with the asd
file from the mp3, I understand why you want to do that. It's
not something we officially support, but I'll check if there's a way,
maybe you just need to touch the asd file (besides renaming it),
so that its modification date is later than that of the .wav/.aiff file?

Thanx for the statement, it´s good to know that you are on it and that the reason is fixable somehow.

To your P.S.:
The only workaround for now is to replace the mp3 by it´s decoded big brother from the decoding cache, this works without a problem for me via the replace button in clip view, Live reanalizes the sample and creates a new asd file corresponding to the wav file´s name in the decoding cache.
So for now I put my buggy mp3´s inside a folder for later bug fixed use and drag my wav with the new asd from the decoding cache to the mp3´s initial location.
I suppose the new asd file is exactly the same as the old one wich was created on the info from the decoded file (with all the markers in place), beside it´s name and the few internal changes (modif. date?) you mentioned? But as you get a brand new asd file by replacing the sample I don´t understand why you want to touch an asd file wich Live already replaces by a newer up to date one.

It would be helpfull then to know wich encoder the download sites use for the moment, as it wasn´t always like that?
Anyway, thanx for jumping in!

Greetings

thanks for the reply if i can be of any help let me know. i'm just glad its resolved.

Serotoninsteve,

you are right, sorry for the confusion, I changed that myself back in August,
touching is not needed anymore: if the asd file is older than the audio file,
Live reanalyses, but tries to keep the marker and loop settings if possible.
Only if that is not possible, for example because the audio file got
shorter than the end of the loop, the clip is reset.

What do you mean with "which encoder the download sites use"?

Ralf

Ralf wrote:Serotoninsteve,

you are right, sorry for the confusion, I changed that myself back in August,
touching is not needed anymore: if the asd file is older than the audio file,
Live reanalyses, but tries to keep the marker and loop settings if possible.
Only if that is not possible, for example because the audio file got
shorter than the end of the loop, the clip is reset.

What do you mean with "which encoder the download sites use"?

Ralf

Hi Ralph,
as this problem only occurs with mp3´s i purchased shortly from them, means that older stuff is working ok, I thought that the problems could be related to a specific codec wich they use now (but not before) to encode their files. I assume that it shouldn´t matter how they where encoded, only how Live handles the decoded output? It was just an idea to get that info from them for further investigation.
Just let me know if I can help in some manner on this problem.

Greetings

Hello,

I just thought to let you know what the current state of the
jumping waveform problem is.

The first interesting finding is that the normal case for mp3 decoding
is not that you get exactly the same material as the input, but that
delay is added before and after the waveform. I.e. the extra 50 ms
delay (silence) at the beginning and the end of the material are normal.
They cannot be avoided.

The question is now - how much delay. While the delay added by the
encoder varies, the one which is really interesting for us is that of the
decoder, the decoding delay.

It should not vary, according to the standards, and it does not for most
of the decoders. See http://mp3decoders.mp3-tech.org/decoder ... tml#delays
for example.

There are known decoders which add less silence at the start,
for example the mp3source decoder (or lame, if you decode into files).

Still I have no proof that our users were using one of these decoders.
Detection is difficult because usually when the problem occurs
(i.e. silence is added) its because the bad decoder is already gone.

So I think there might be another problem than just such a decoder.
I hope that somebody who can reproduce the problem will give
me enough information to find out what's going on.

Concerning possible fixes, first of all I will not decide what to do
before the problem is not reproduced, for it can be something more
complicated than just a decoder with less delay.

For the varying delay. the fix would be to deliver a well-known mp3 file
with Live, which is decoded to see what the decoding delay is, and to
compensate it if it differs from the delay we measure here at Ableton
with the standard decoders, in the assumption that the delay does
not differ from file to file (we'd need one for vbr and one without,
their delays vary).

Also, we already have a fix in the next Live release which uses the
ACM codecs delivered with various applications (e.g. Windows Media Player
9 etc.), in favour of other DirectShow decoders, which have a reputation
of good correctness and high reliability.

Ralf

Hi all,
here is a link to a small set (14Mb) with wich one I can reproduce the jumping waveform on my machine:

http://s51.yousendit.com/d.aspx?id=0BSG ... MKT28PK6LB

The link is limited, so please download only if you have problems or want to help on this problem.
I´ve included 2 separate .asd files wich have the same warp info, but different sizes. On my machine the jumping waveform appears only with one of the .asd´s, so just copy the different asd´s into the sounds folder and reopen the set and see what happens. Please let us know what you experience otherwise.
I´m on XP home and have quicktime installed.

Greetings