Hello all. I am fairly new to the creation of dynamic websites and my question might be rather easily answered, but no one in my office has a clear answer as to why the following happens.
I have a database that has the start and stop times of audio segments. Not chapters per se, but short segments (words, phrases, phonemes, etc.) listed next to play buttons that in theory, when you click on the play button a browser window pops up and the sound plays. This works locally and on most browsers but is not entirely consistent. However this is not my main problem.
My main problem is that the time stamps from the wave form, that is the actual start and stop times from the mp3/m4a files (.wav files would be simply too large to try to make work regardless) do not match the time stamps (starttime and endtime parameters) that the html code requires for the correct segment to play.
In essence, the "real times" (from the waveform) and the times entered to play the correct segments do not in all cases match, and in cases where they do not match the amount of misalignment is not consistent.
My thoughts are that this problem is an artifact of the audio container formats, and that there is little I can do to fix this save find correct the correct audio formats.
My supervisor wants however a clear and full explanation of why this is the case. I cannot at this time give him the technical reasons why this would be the case, only what I would intuit to be the reason.
So, my question is: Am I correct about the main reason for this misalignment effect? If I am what documents or technical reports may I look to for textual support? If I am not correct in what way am I not correct? And lastly, if it is the audio container format that is the culprit, what audio container format would be best to use to fix this problem or at least be consistent?
Thank you sincerely,
PJMidtlyng
How are you playing the audio files in the browser, using the user's default handling application?
I don't understand what "the time stamps (starttime and endtime parameters) that the html code requires for the correct segment to play" refers to. What HTML code?
Edit: Also, what format are you storing the timings in? Floating point seconds value? Example code/values may be nice.
I don't understand what "the time stamps (starttime and endtime parameters) that the html code requires for the correct segment to play" refers to. What HTML code?
Edit: Also, what format are you storing the timings in? Floating point seconds value? Example code/values may be nice.
QUOTE (Synthetic Soul @ Sep 11 2008, 08:26) 
How are you playing the audio files in the browser, using the user's default handling application?
I don't understand what "the time stamps (starttime and endtime parameters) that the html code requires for the correct segment to play" refers to. What HTML code?
Edit: Also, what format are you storing the timings in? Floating point seconds value? Example code/values may be nice.
I don't understand what "the time stamps (starttime and endtime parameters) that the html code requires for the correct segment to play" refers to. What HTML code?
Edit: Also, what format are you storing the timings in? Floating point seconds value? Example code/values may be nice.
Ok, here's the code. I've bolded what it is i am referring to.
<html>
<head>
<meta name=Title content="Digital Maya Website Audio">
<meta name=Keywords content="">
<meta http-equiv=Content-Type content="text/html; charset=macintosh">
<LINK REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>
<title>Digital Maya Website Audio</title>
<script>
function playFile(soundObj)
{
var thissound=eval("document."+soundObj);
thissound.Play();
}
</script>
</head>
<body bgcolor=white lang=EN-US style="border:0;margin=0;align=center">
<div class=Section1>
<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" codebase="http://www.apple.com/qtactivex/qtplugin.cab" width=50
height=26>
<param name="src" value="lesson_1_basic_sentences.mp3">
<param name="scale" value="tofit">
<param name="controller" value="true">
<param name="autoplay" value="true">
<param name="loop" value="false">
<param name="starttime" value="00:00:06:07">
<param name="endtime" value="00:00:07:15">
<embed src="lesson_1_basic_sentences.mp3" name="s001" scale=tofit width=1 height=1 align=left
controller=false autoplay=true loop=false starttime="00:00:06:07" endtime="00:00:07:15" enablejavascript=true
pluginspage="http://www.apple.com/quicktime/download/" type="video/quicktime"></EMBED></OBJECT>
<img src="http://www.webucateus.com/dotnetnuke/Portals/0/Cache/images/soundIcon.gif" height=50 onClick="playFile('s001')"/>
<!--a href="" onClick="playFile('s001')"/>PLAY</a-->
</div>
</body>
</html>
So the starttime and endtime parameters in the code say times X is the start playing time and Y is the end playing time. Yes these are floating points, as much as I understand what that means.
If i take the audio file that is the source for this code, and open it in audacity, or Peak Pro, or praat, and find the exact segment I want (in this case the phrase "Basic sentences") the times which are on the wave form are not X for the start time and Y for the end time, but two completely different values.
When I put in the actual (that is waveform) values the sound doesn't play correctly. It is either cut off early, late, or plays a completely different section of audio. And when I adjust the start time and end time parameter values to play the correct segment, those values inputed on the waveform do not correspond to the correct section of the waveform. Indeed, sometimes the parameter values on the waveform select for silence, or cut off the audio early or late.
I hope this clarifies. Essentially I am trying to minimize the numbers of mp3s, or really audio files in general on the webpage. By using the start and end time parameters it was our thought that when the sound icon was clicked on, the audio that played would correspond to those values. in practice, this is not the case.
I've tried the quicktime plug-in (the one currently in this code), the adobe flash, and Windows media players. None seem to rectify the problem and behave similarly.
If there's anything else I forgot to include, let me know.
thanks and best,
pjmidtlyng
I guess this all depends on the method in which you are embedding the audio. You have provided QT code so I can only go with that.
A quick search shows me that QT uses HH:MM:SS:FF format:
My thought is that your issue is with the conversion from your database timings into this format. When I asked about floating point numbers I was really enquiring whether you store the timings in seconds in your database, using floating point numbers, e.g.: 123.456, to represent 2 minutes, and 3.456 seconds.
To conclude: I wonder whether the conversion between the format in which you store the values and the format that the plug-in (QT in this instance) requires is the issue. That said, I have no idea how far out the timings are at the moment, and whether my assumption is completely off the mark.
One thing to note here: with QT 1 frame is 1/30 of a second. FYI: cue sheet frames are 1/75 of a second. You can see how conversion discrepancies happen.
Edit: I should also point out that I have no experience in this area: seeking to a specifc point in a media file with a browser plug-in. It is possible that none you have tried are able to seek in MP3/M4A files as accurately as you desire.
A quick search shows me that QT uses HH:MM:SS:FF format:
QUOTE
This attribute takes a time value in the form Hours:Minutes:Seconds:Frames (30ths). The frames component can be specified as a fixed point number so that more specific times can be specified for instance 3:30:22.5 means 3 minutes, 30 seconds and 22.5 frames.
My thought is that your issue is with the conversion from your database timings into this format. When I asked about floating point numbers I was really enquiring whether you store the timings in seconds in your database, using floating point numbers, e.g.: 123.456, to represent 2 minutes, and 3.456 seconds.
To conclude: I wonder whether the conversion between the format in which you store the values and the format that the plug-in (QT in this instance) requires is the issue. That said, I have no idea how far out the timings are at the moment, and whether my assumption is completely off the mark.
One thing to note here: with QT 1 frame is 1/30 of a second. FYI: cue sheet frames are 1/75 of a second. You can see how conversion discrepancies happen.
Edit: I should also point out that I have no experience in this area: seeking to a specifc point in a media file with a browser plug-in. It is possible that none you have tried are able to seek in MP3/M4A files as accurately as you desire.
I think I understand that. Thank you.
I have been operating it seems on an incorrect notion, that of milliseconds versus frames. This is a foolish assumption no doubt; my expertise being in audio editing.
Is there a conversion formula for hours:minutes:seconds:milliseconds to hours:minutes:seconds:frames? Or vice versa? So that one may be able to predict the converted times?
Thanks again. If this is not the answer at least I have a new avenue of research to find more answers.
I have been operating it seems on an incorrect notion, that of milliseconds versus frames. This is a foolish assumption no doubt; my expertise being in audio editing.
Is there a conversion formula for hours:minutes:seconds:milliseconds to hours:minutes:seconds:frames? Or vice versa? So that one may be able to predict the converted times?
Thanks again. If this is not the answer at least I have a new avenue of research to find more answers.
Well, to convert milliseconds to QT frames you would just need to multiply the value by 30/1000, or 3/100:
I guess if you are passing QT a value like 00:00:01:750 it may interpret this as 00:00:26:00 (as 750 QT frames == 25 seconds), so I may actually be right. Blimey.
Edit: as a rough guide, here's a few key values converted from milliseconds to QT frames:
NB: I have no idea how good the QT plug-in is, or how widespread it is. If you would prefer to use a Flash player then go for it... just ensure that your timing conversions are spot on.
CODE
frames = milliseconds * (3/100)
I guess if you are passing QT a value like 00:00:01:750 it may interpret this as 00:00:26:00 (as 750 QT frames == 25 seconds), so I may actually be right. Blimey.
Edit: as a rough guide, here's a few key values converted from milliseconds to QT frames:
CODE
Milliseconds | Frames
-------------+-------
10 | 0.3
25 | 0.75
50 | 1.5
100 | 3
250 | 7.5
500 | 15
750 | 22.5
-------------+-------
10 | 0.3
25 | 0.75
50 | 1.5
100 | 3
250 | 7.5
500 | 15
750 | 22.5
NB: I have no idea how good the QT plug-in is, or how widespread it is. If you would prefer to use a Flash player then go for it... just ensure that your timing conversions are spot on.
I may be wrong here:
a millisecond - 1/1000 seconds
a frame is 1/30 seconds
1/30 / 1/1000 = 33.333333
There are 33.33333333 milliseconds per frame.
Surely it's:
C.
Please correct me if I'm wrong
{EDIT ---- Oooops --- THINK I'M WRONG --- sorry!!!!!}
a millisecond - 1/1000 seconds
a frame is 1/30 seconds
1/30 / 1/1000 = 33.333333
There are 33.33333333 milliseconds per frame.
Surely it's:
CODE
frames = milliseconds * (100/3)
C.
Please correct me if I'm wrong
{EDIT ---- Oooops --- THINK I'M WRONG --- sorry!!!!!}
CODE
milliseconds = frames * (100/3)
CODE
x = 500 * (100/3)
x = 500 * 33.333
x = 16666.67
x = 500 * 33.333
x = 16666.67
Um... no.
CODE
x = 500 * (3/100)
x = 500 * 0.03
x = 15
x = 500 * 0.03
x = 15
Yay!
CODE
frames = milliseconds / (100/3)
... works.
Whoops!
Back to school!
[EDIT:
Is what I was after.
Divide, multiply, clearly it's all the same to me.
/EDIT]
C.
Back to school!
[EDIT:
CODE
frames = milliseconds / (100/3)
Is what I was after.
Divide, multiply, clearly it's all the same to me.
/EDIT]
C.
That's why I use Excel to test algorithms before I code in PHP (my usual language) or even pseudo-code. Get more than one operator in there and my brain starts hyperventilating. 
If it makes you feel any better I started off using centiseconds instead of milliseconds for some unknown reason...
If it makes you feel any better I started off using centiseconds instead of milliseconds for some unknown reason...
Funny thing is I did test it on Excel
Still managed to get it the wrong way round somehow between Excel and HA !!
OMG.
C.
Still managed to get it the wrong way round somehow between Excel and HA !!
OMG.
C.
Synthetic Soul--blimey, yes you are right.
Here's some actual numbers. I'll call them audio time to refer to h:m:s:ms and QT time to refer to h:m:s:f
audio time: 00:00:09:15 to 00:00:09:94 plays "Greetings"
QT time: 00:00:09:06 to 00:00:09:28 plays "Greetings"
Entering the audio time in the qt plug-in plays not "Greetings" but "ngs Pedro" (which in audio time is ~ 00:00:09:58 - 00:00:11:41.
Employing the conversion that Synthetic Soul puts forward we convert the QT time to audio time and we get 00:00:09:45 and 00:00:11:82. Which we can see approximately predicts the shift in the start time and end time.
The QT time values, that is the values that are in h:m:s:f when converted to h:m:s:milliseconds gives us 00:00:09:20 and 00:00:09:93. Which again approximately predicts the misalignment.
The conversion from frames to milliseconds seems to more closely predict the misalignment than the milliseconds to frames, but regardless, at least I know what I'm up against. This has been extraordinarily helpful. Thanks so much.
pjmidtlyng
Here's some actual numbers. I'll call them audio time to refer to h:m:s:ms and QT time to refer to h:m:s:f
audio time: 00:00:09:15 to 00:00:09:94 plays "Greetings"
QT time: 00:00:09:06 to 00:00:09:28 plays "Greetings"
Entering the audio time in the qt plug-in plays not "Greetings" but "ngs Pedro" (which in audio time is ~ 00:00:09:58 - 00:00:11:41.
Employing the conversion that Synthetic Soul puts forward we convert the QT time to audio time and we get 00:00:09:45 and 00:00:11:82. Which we can see approximately predicts the shift in the start time and end time.
The QT time values, that is the values that are in h:m:s:f when converted to h:m:s:milliseconds gives us 00:00:09:20 and 00:00:09:93. Which again approximately predicts the misalignment.
The conversion from frames to milliseconds seems to more closely predict the misalignment than the milliseconds to frames, but regardless, at least I know what I'm up against. This has been extraordinarily helpful. Thanks so much.
pjmidtlyng
With the figures that you are providing (and the fact that you consistently provide only two digits for ms) it looks to me as though I was actually right when dealing with centiseconds.
If we use:
... to convert centiseconds to frames we would get:
Therefore, I would suggest that you use the following instead:
Bear in mind that 75 milliseconds are not the same as 75 centiseconds; 750 milliseconds are, but removing the third digit, or rounding to two digits does not work this way. In essence, if your fourth value is a range between 0 and 99 - and not 0 and 999 - then you are dealing in centiseconds, and not milliseconds.
If we use:
CODE
frames = milliseconds * (3/10)
... to convert centiseconds to frames we would get:
CODE
00:00:09:15 > 00:00:09:04.5
00:00:09:94 > 00:00:09:28.2
00:00:09:94 > 00:00:09:28.2
CODE
00:00:09:50 > 00:00:09:15
00:00:12:13 > 00:00:09:94
00:00:12:13 > 00:00:09:94
Therefore, I would suggest that you use the following instead:
CODE
frames = milliseconds * (3/10)
milliseconds = frames / (3/10)
milliseconds = frames / (3/10)
Bear in mind that 75 milliseconds are not the same as 75 centiseconds; 750 milliseconds are, but removing the third digit, or rounding to two digits does not work this way. In essence, if your fourth value is a range between 0 and 99 - and not 0 and 999 - then you are dealing in centiseconds, and not milliseconds.
Yes, this is indeed true. Rounding was a function of ease of data entry for others working on the project. I tested this myself with three digits after my last post and that did account for the problem exactly.
Thanks for your very thorough help. It is very appreciated.
Thanks for your very thorough help. It is very appreciated.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.