The definitive quasi-scientific answer on auto t.mark with line-in

[dex Otaku]

I am quite happy to announce [not for the first time] that I'm completely wrong about something!

Sony fixed the issue I have been complaining about for some time now - the "repeated sections" problem I and a few others had previously reported experiencing when making line-in recordings.

I had been falsely attributing this problem to a hardware bug [based on bad assumptions on my part], but yesterday, MDCF user Top Cat mentioned:

Audio with trackmarks removed prior to uploading have never been found to contain repeated sections (and I do such uploads a lot)

This got me to thinking and theorising as is occasionally my nature, and I decided to finally test this for myself this evening.

The end result was - in HiLP, HiSP, and PCM modes, using both my recorders [NH700 and RH10] and SS 3.4, that this problem is now completely non-existent [for me at least].

For those of you who are interested in the technical aspects of how I did this test, keep reading below.

For those of you who aren't - it's official at my end at least that uploaded line-in [analogue] recordings have no "repeated sections" problem, and SS now combines tracks just fine.

Modus Operandi a.k.a. what obsessive-compulsives do with their evenings

This test was performed identically with the NH700 and RH10. All NH700 recording, editing, and uploading were done on that unit alone; all RH10 recording, editing, and uploading were done with the RH10 alone.

I created a 2-minute long test file consisting of the following: <ul><li> .1 second 880Hz tone repeated at one second intervals, alternating left and right channels [@ -56dBfs] </li><li> .25 second "scale of A's" [looped] consisting of A4 through A8 with a length of .05sec each, with right channel delayed .125 second [@ -57dBfs] </li><li> 4 second sweeptone [looped] from 1kHz-6kHz, with right channel phase inverted [@ -56dBfs] </li><li> 2 second 880Hz tone at random intervals between 2-3.8 seconds apart [@-3dBfs] </li></ul>The purpose of this was to create a test track which contained a patterned low-level signal along with bursts of louder tone which would trigger the recorder's auto-trackmarking. Upon playback after uploading, the low-level pattern would easily break, containing plainly audible glitches and repeats, if trackmarking was indeed causing any sort of fault during recording, SS's uploading or combining process[es], or the recorders' combining process.

The test track, if you'd like to hear it for yourself, can be obtained in the format of your choice if you PM me.

Given the short interval of each note in the ascending A's loop-track, and the .125sec delay between channels, this should make any repeat of between .05 and .25 second plainly audible. The sweeptone further increases the resolution of audible error, though the ascending A's what was I really relied upon when listening. The lengths of the two combined loops should account for repeat lengths between .05sec and 4 seconds total. Or at least, that's how my logic works.

I recorded the test track 3 times on each unit, once for each available HiMD bitrate [HiLP 64kbps, HiSP 256kbps, and LPCM]. Since neither exact levels nor fidelity were crucial to this test, I simply ran a line from the headphone output of my Logitech Z680 controller to the line-in of the recorders, and "calibrated" so that the pattern was off the bottom of the units' level meters while the tone bursts were between the centre hash mark [-12dBfs] and the top.

In each case, I ended up with 19 tracks marked automatically by the recorder.

I then:<ul><li> uploaded all of the resulting tracks to SS, and converted them to WAV in separate folders </li><li> combined the tracks of each bitrate from each recorders with SS, and exported the resulting single track for each to WAV to the same folders as the previous step </li><li> combined the tracks for each bitrate on both recorders themselves, then uploaded the resulting tracks and exported to WAV to the same folders again </li></ul>The result was that I then had 3 versions of each recording for each bitrate from both recorders; each copy from the same original could be compared directly, i.e. uncombined vs. SS combined vs. unit combined.

Listening was done with a compressor set to raise the low-level part of the signal and completely silence the tone bursts [within the limits of the compressor's attack and decay]. This output was then put through the Dolby Prologic II "Film" mode of my Z680s [which steered discretely side-directed elements to the front left and right, with some overlap in the centre channel, and the sweeptone almost discretely in the rear channels [accounting for points where the same frequency happened to overlap from the ascending A's]].

The results were: [all lengths in samples]<blockquote><pre>Recorder | Mode | Uncombined | SS-combined | Unit-combined

====================================================================

NH700 | HiLP | 5,475,984 | 5,475,984 | 5,475,984

| HiSP | 5,465,744 | 5,465,744 | 5,465,744

| PCM | 5,475,360 | 5,475,360 | 5,475,360

---------------------------------------------------------

RH10 | HiLP | 5,258,896 | 5,258,896 | 5,258,896

| HiSP | 5,469,840 | 5,469,840 | 5,469,840

| PCM | 6,152,640 | 6,152,640 | 6,152,640

=========================================================

lengths vary due to manually starting and stopping the units

spot the oldbie making ASCII tables because they work:*P</pre></blockquote>There's a slightly obvious pattern emerging here - the length in samples is as it should be: identical whether tracks are uploaded and exported as marked by the unit, combined by SS, or combined on the unit itself. I'm actually rather impressed that the length was exact to the single sample.

Also of possible interest to technerds:<blockquote><pre>Recorder | Mode | Avg. T.Mark Time from rising slope

=========================================================

NH700 | HiLP | -155ms

| HiSP | -150ms

| PCM | -140ms

----------------------------------------------

RH10 | HiLP | -160ms

| HiSP | -165ms

| PCM | -145ms

==============================================

numbers denote the time between the actual trackmarks

and the rise in levels that triggered auto t.mark</pre></blockquote>Trackmarks would only appear to be placed if levels fell below -45dBfs for longer than 2 seconds, followed by a rise in levels above -12dBfs.

Well, there it is, folks. The problem is quite evidently no longer a problem. Thank you, Sony! [but I really, REALLY wish you would include release notes with a changelog along with each version of SS. Really. It would be very useful, especially for those of us who like to go around asserting that there's a problem that was probably fixed 2 or 3 sub-versions of the software ago.]

[greenmachine]

Thank you Sony and thank you dex, this is great news for live recordists. Any problems uploading unit-combined tracks? What about uploading combinined tracks where the recorder has been stopped in between [and the TOC (or whatever it is called) been written]? (I don't plan to do this often, just curious about reliability of unit-combined tracks in general)

[dex Otaku]

Any problems uploading unit-combined tracks?

Um. That WAS part of the test I just detailed. :*)

What about uploading combinined tracks where the recorder has been stopped in between [and the TOC (or whatever it is called) been written]?

No idea. I don't suspect there would be any problem with it, other than the obvious glitch it would cause [because the audio isn't contiguous].

[dex Otaku]

addendum:

Actually, greenmachine, I suppose it wasn't explicity stated in there...

At no point during the above procedure did I experience any errors on either HiMD recorder. At no point did I experience any problems of any kind with SS. Every single operation went without a hitch.

[motown_junky]

Thanks, this is indeed great news !! However glitches in my recordings were caused by adding track marks manually on the unit to a contiguous track which sounded fine on the unit but when uploaded through SS the repeated sections could be heard, would this problem also now be resolved ?

[cryinglandscape]

Wow, thank you for taking the time to put together this detailed analysis, dex Otaku! This is good news!

[Killroy]

Hello,

thank you too, Dex, for this really scientific analysis!

I want to add an experience of myself to this topic that perhaps might be interesting too:

Whenever I use my MZ-NH600 for recording of FM Radio broadcasts, it always seems strange to me that my unit never ever automatically inserts any trackmark - not even into continguous recordings of >2hrs in length.

Could this be, because the radio program never contains any section of sufficient silence that woud trigger a trackmark? This does not seem much probable to me.

Or could it be the 19 kHz pilote-tone that continuously comes along with FM stereo broadcasts (at least here in Europe)?

If the second is the reason, would it be feasable for live recordists to add a similar and unnoticeable hi-frequency signal to the (analogue) input and completely avoid auto trackmarks that way?

Cheers - Killroy.

[dex Otaku]

Whenever I use my MZ-NH600 for recording of FM Radio broadcasts, it always seems strange to me that my unit never ever automatically inserts any trackmark - not even into continguous recordings of >2hrs in length.

Could this be, because the radio program never contains any section of sufficient silence that woud trigger a trackmark? This does not seem much probable to me.

I've experinnced this as well, from both radio and TV [news]. I don't find it suprising that this happens at all; generally speaking, the audio of both are extremely compressed, and actual blank sections are a real rarity. "Dead air" is a bad thing .. it loses the audience.

It's also not impossible that the stereo pilot tone could be messing with the recorders, though at least half of the recordings I've made that I experienced this with were from mono sources [FM mono].

[dex Otaku]

The test file: [attachmentid=1480]

NOTE: This is a 192kbps atrac3plus file, renamed to .zip so it would be allowed as an attachment. If you download this track, you must rename it to .OMA before you can do anything with it.

thresh_tests_02.zip

[ozpeter]

Very nicely worked out test. However, the proof of the pudding would be to repeat the test with an older version of SS and see what the differences are. Something personally I can't be bothered to do so I can't blame you for not having totally proved the point that way! However, the other way to prove the point would be to upload a previously problematic file and see what the result is. I might be able to try that, if I can find the one I have in mind.

[dex Otaku]

Very nicely worked out test. However, the proof of the pudding would be to repeat the test with an older version of SS and see what the differences are. Something personally I can't be bothered to do so I can't blame you for not having totally proved the point that way!

Yes, exactly. Hey, I did say quasi-scientific.

Among the problems with that:

* I have only one system here to test with. It's the one I use every day. Reverting versions is a bad idea.

* Has anyone been archiving the [standalone installer] older versions? The only ones I have on disc are 2.0 and 3.0.

* I never keep my recordings on the original discs

I do have the uncombined copies [exported WAVs] of the first recording I noticed the problem with [uploaded and exported with SS 2.3], but that won't help. It has repeated section at almost every trackmark. And there are about .. 700 of them [28-30 hours of line-in recordings].

Doing the test itself doesn't actually take that much time .. I can send the test file as WAV to anyone who wants a copy, and they could test it with other units and other versions of SS if they still have them. The time required is about 10 minutes to record the audio, then the time it takes to upload and export .. then to combine with SS and export .. then to combine on the recorder, upload, and export again. It takes about half an hour in total, followed by either comparing file sizes or dropping everything into a NLE and comparing lengths.

And, yeah, well. I doubt basically anyone else here would invest the time in that, actually.

This does bring up another issue altogether, though - for comparison's sake, it might be valuable to actually have an archive of the different versions somewhere. The easiest wa to manage this would be for someone with a CD of any given version to make an ISO image of the CD and upload it somewhere - or to copy the SS install folder and zip it for upload.

It may or may not be wasted time. Perhaps if other users might express whether they have any interest in doing this..? [Hey - perfect time for community effort. This is a community, after all.]

[ozpeter]

Well.... I'm pretty sure the audio I have just retransferred from Hi-SP to wave using an NH900 is the audio which caused my concern about little repeats at track marks in the past, and it certainly does not seem to be amiss now. It's quite good test material, being simply the sound of people talking quietly on stage in a large hall after a rehearsal, with footsteps or other small transients triggering auto track marks at frequent intervals. Before, I could not only hear the repeats but zooming in on the waveform in Audition I could clearly see the repeats.

So... a cautious "thank you Sony" from me too - if I have any cause in the future to doubt that the problem has been fixed, you can be sure I shall be back here like a shot to report it!

Just read what you posted about an archive of versions - the installers posted here would presumably form that, if they have been kept? - which they must have been, somewhere by someone, if only by the hero who prepared them in the first place?

[dex Otaku]

Just read what you posted about an archive of versions - the installers posted here would presumably form that, if they have been kept? - which they must have been, somewhere by someone, if only by the hero who prepared them in the first place?

Well.. first, they haven't all been prepped by the same people.. and second, I have noticed threads where users who wished to downgrade because of problems caused by upgrading have not been able to find the version they'd been using previously - including versions that were available here at one point or another. I don't check the downloads section that often, though.

[Christopher]

I have the old versions (at least to 3.1, perhaps 2.0 if I looked really hard), but I've been reluctant to put them in the Downloads section because it can introduce quite a bit of confusion.

[dex Otaku]

I have the old versions (at least to 3.1, perhaps 2.0 if I looked really hard), but I've been reluctant to put them in the Downloads section because it can introduce quite a bit of confusion.

Cool. As long a someone has them..

[reefbeef]

Does SS 3.4 pause playback at trackmarks as in previous versions?

Example:

Hook up HiMD recorder via usb and play live recording in transfer window. Previous SS versions would momentarily pause at each track mark

I still upload using the paranoiac's method, and this has been a problem in the past.

If it is still a problem, I guess I'll have to continue setting auto track mark to 60 mins. on my NH1.

[dex Otaku]

Does SS 3.4 pause playback at trackmarks as in previous versions?

As far as I know, yes. I don't know that this problem might be fixable, as playback via USB is not buffered like play on the unit is [making gapless support difficult as the least].

I still upload using the paranoiac's method, and this has been a problem in the past.

Wow. You must have lots of time to kill. I quit using it myself after SS 2.3 came out [and have lost maybe 4 tracks in total since then, out of perhaps 60 hours of audio, all because of unrecoverable write errors caused by impact/vibration durin recording, which preliminary testing at this point suggests SS 3.4 also overcomes].

[reefbeef]

Now that SS 3.4 doesn't freeze my discs from editing after upload, uploads reliably, and doesn't leave gaps at the track marks - I may have to ween myself off of the paranoiac's method.

Thanks, Dex.