<div dir="ltr">I have not been able to exactly reproduce this problem on WT 4.16, but I am using the Fraunhofer CODEC instead of LAME.  There's a note in the Release notes about this:<div><br></div><div><br></div><div><div><font face="monospace, monospace">- MP3 setup : Only the CBR codecs are now displayed in the setup</font></div><div><font face="monospace, monospace">  dialogs. The usage of the ABR codecs (most of the LAME ACM ones) is</font></div><div><font face="monospace, monospace">  too erratic to be trusted in.</font></div></div><div><br></div><div>(CBR = Constant Bit Rate, ABR = Average Bit Rate)</div><div><br></div><div>Win-Test uses interpolation to locate the correct offset within the MP3 file.  It records the timestamp of every QSO precisely, when it is logged, but then it must use interpolation to <i>approximate</i> the offset to the audio clip within the MP3 file.  Maybe that has something to do with it.<div><br></div><div>Tip:  to enable the fixed bit rate Fraunhofer CODEC on Windows 7 and later, 32-bit or 64-bit, and run the batch file referenced here:</div><div><br></div><div><a href="http://www.komeil.com/blog/enable-fraunhofer-mp3-l3codecp-acm-windows">http://www.komeil.com/blog/enable-fraunhofer-mp3-l3codecp-acm-windows</a><br></div><div><a href="http://www.komeil.com/download/264">http://www.komeil.com/download/264</a>  (click the small blue download button, nothing else, then run the batch file, as administrator)<br></div><div><br></div><div>It's a little scary to run this batch file because it updates the Windows Registry (be sure to download, right click on file, and select "Run as Administrator"), but it has worked very well for me on multiple computers with no apparent side effects.</div><div><br></div><div>In WT 4.16, you can set the "Time Before QSO was Logged" to a minimum of 1s, but not 0s.  However, it still seems to start the recording about 15 seconds before the QSO was logged, not 1 second, so it does work rather mysteriously.  But I am using an 8000 Hz sample rate and a 24 kBit/s bit rate.  Perhaps when other rates are used, the QSO offset isn't calculated precisely.  Or there could be a subtle bug in the Contest Recorder offset calculations at certain bit rates.</div><div><br></div><div>Please tell us exactly which CODEC, Sample Rate, and Bit Rate you have selected so we can try to replicate the problem.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">73,<div>Bob, N6TV</div></div></div>
<br><div class="gmail_quote">On Wed, Apr 1, 2015 at 1:28 PM, Tonno Vahk <span dir="ltr"><<a href="mailto:tonno.vahk@gmail.com" target="_blank">tonno.vahk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A small thing. When you play a QSO recording from the log with AltGr+Enter<br>
everything is fine and recording starts at correct time. But when you<br>
Extract and Save QSO the recording starts considerably earlier even if you<br>
set Time Before QSO Was Logged to zero. That means in order to get normal 30<br>
sec to 1 minute audio clip one has to actually extract the next or one after<br>
next QSO!<br>
<br>
Any ideas why this happens? It is pretty inconvinient especially if there is<br>
no immidiate next QSO. I remember that way back it worked fine but this<br>
issue has developed at some point of time..<br>
<br>
73<br>
Tonno<br>
Es5tv<br>
<br>
_______________________________________________<br>
Support mailing list<br>
<a href="mailto:support@win-test.com">support@win-test.com</a><br>
<a href="http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support" target="_blank">http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support</a><br>
</blockquote></div><br></div></div></div>