track markers and repeating audio

[cryinglandscape]

Hi there,

I've been reading up on this site about how SonicStage causes a small repeat of audio at points where track markers were inserted during import. Has anyone found a cause or cure for this? Can it be avoided by removing all the track markers on the minidisc and then importing? Does this happen only when markers are inserted because the audio volume is very low or does it also happen when it inserts a new marker every 5 minutes. Is there any good way to get around this on the MZ-RH10 (I am very anal about my recordings)? Thank you for your help!

Peace,

Jason

[A440]

The most recent version of SonicStage, 3.4, seems to have no problem uploading tracks that were joined on the machine--that is, where an existing track mark was removed by pausing, going to the track mark (Mark xx) and removing it by pushing the track button.

For previous versions, at least up to 3.3 (which I never tested), this was a huge problem. It seems to be fixed.

How the track marks got there--by timer or with low level--doesn't matter.

Please, before you depend on it, do a test with your unit and your SonicStage. Record something non-crucial, add and remove some track marks, and see how it uploads. I have had no problems with tracks that used to be 7 or 8 separate tracks, but I never entirely trust SonicStage.

[dex Otaku]

I've been reading up on this site about how SonicStage causes a small repeat of audio at points where track markers were inserted during import. Has anyone found a cause or cure for this? Can it be avoided by removing all the track markers on the minidisc and then importing? Does this happen only when markers are inserted because the audio volume is very low or does it also happen when it inserts a new marker every 5 minutes. Is there any good way to get around this on the MZ-RH10 (I am very anal about my recordings)? Thank you for your help!

As has been stated in the other threads that talk about this:

* it only happens when recording with line-in [which has auto-trackmarking which can not be turned off]

* the repeated sections are made by the recorder itself while recording, not during the import process

* this is a hardware issue, not a software issue

I suspect that combining tracks on the disc itself before uploading will not get rid of the repeated sections, as they are caused by the recorder in the first place.

The only way to get around this is to upload, convert to WAV, and then check every track boundary during editing - and remove every repeated section yourself.

[cryinglandscape]

Thank you for your help! I have a few quick questions since the information I can dig up on this forum is scattered. Based on the discussions I've read, it seems that this issue may only occur on the NH900 unit. Is this true? Seccondly, it has been suggested that this is a problem with the HI-SP compression algorithm, so my understanding is that PCM recording should not be affected. Is this correct? Again, hank you for all your help!

[dex Otaku]

I have experienced this with the NH700 and RH10, in HiSP and PCM modes. My assupmtion is that the fault applies across all models of both generation 1 and generation 2 recorders.

It appears to be caused by a bug in the track marking routine's seek-ahead buffer, and could be related to the sector size used by HiMD or by the framesize of whichever format is being recorded.

Depending on what you're recording, this may or may not be a problem for you. The only time it's actually bothered me was with a live recording [30+ hours worth] made "off the board" via line-in [of both the NH700 and RH10 at different times] .. crowd noise, stage noise &c. would experience tiny repeated sections at the trackmarks. If your recording doesn't have background noise like this, you shouldn't even be able to notice that it's happening.

[cryinglandscape]

Thanks for your help! Am I correct in thinking that this only happens at points where the volume dips below the threshold (I will be recording live concerts)?

[dex Otaku]

Thanks for your help! Am I correct in thinking that this only happens at points where the volume dips below the threshold (I will be recording live concerts)?

The general rule of how auto t.mark works is when levels fall below the thresh for >=2secs a mark is placed.

I don't actually know what the threshold is, though I do know - if you have highly compressed content coming in [such as radio broadcasts or TV news], levels rarely fall below the threshold long enough to cause any marks to be placed. I've plugged the output of my VTR/tuner into my recorder to make test recordings in the past and ended up filling whole MD80s [2:23 @HiSP] without a single track mark being placed.

If you're recording off the board, you can end up with LOTS of track marks. All those stretches between songs when the band are tuning, switching instruments and what have you .. the conversation of the band with the crowd ends up making plenty of marks. I've recorded shows that ended up with >450 marks on a 1GB disc [again, @ HiSP].

[Top Cat]

All the evidence observed is telling that repeated audio is generated by the MD hardware during upload of the multiple tracks.

Note: I believe this issue may be fixed by software - the software just needs to tell the hardware somehow to ignore the trackmarks

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

A possible explanation might be like this:

- sometimes (everytime?) a recorder finishes transferring a track from disc it has its pick-up a small bit behind the next track's mark (i.e. beginning),

- then a command to read the next track arrives from the host and the recorder has to seek back (this can be heard indeed! - seeking does not occur after removing the marks)

- probably reads are performed by blocks and track marks may be placed in the middle of a block and some weird sircumstances prevent the MD unit from addressing within the block correctly. So the Sony engineers simply chose the safe way to overlap audio reads

[dex Otaku]

Be patient.. I'm thinking out loud, so this is liable to be very messy. I may just be out to lunch from watching too much Stargate: SG-1.

All the evidence observed is telling that repeated audio is generated by the MD hardware during upload of the multiple tracks.

I'm going to disagree and then agree with you, so be patient.

Recording works something like this:

* Unit records audio; first step is buffering the output of the ADC

* Auto t.mark monitors the buffer for levels above/below t.mark threshold before the stream is actually recorded to disc [like a "seek ahead/behind" buffer]

* When levels fall below the threshold, the unit monitors for the next rising slope

* On the next rising slope above the threshold, the unit appears to step -backwards- to the start of that slope and place the mark

* in the meantime, audio has been being written to disc from the buffer; since the t.mark process takes place in the buffer, the writing process is continuous; track marks are written to the TOC when the user hits STOP.

Mind the next section: it's theory, and I'm about to basically invalidate it in the part right after thanks to the brain-prodding Top Cat has provided.

From my previous experience, the "bug" here would probably either be:

* that there is a finite resolution [timewise] for monitoring the threshold that is lower than sample accuracy [same as there's a finite resolution for editing, and that the lower the bitrate you use, the coarser that resolution gets; in fact, the resolution "error" for t.marking actually IS the editing resolution]

- or -

* that the buffering is stepping back to the beginning of the next rising slope above threshold to mark BUT is also neglecting to omit the back-tracked audio from the end of the previous track [which appears to be the case from my experience]

If the former is the case, then combining tracks on the unit might actually get rid of the repeated sections [noting that this did not work for me with HiSP recordings from both the NH700 and RH10]. The latter case actually could be a bug based on poor implementation of the former.

Okay. That was me disagreeing. Now on to the agreeing part, because you've made me think about it in greater detail...

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

I must confess that I never listen critically to my recordings on the originating discs themselves. Most of the time, the first I hear of my recordings is actually in my NLE software.

Assuming that playback is without repeated sections on the discs themselves [agreeing with you], this does suggest that the problem is caused during SS's uploading process, and that the above cases I typed out 20 minutes ago are both false.

If the audio on the original disc is indeed completely seemless, and the fault is in the uploading process, then perhaps the real issue here is that SS is trying to conform all tracks to 75fps so they can be burned to CD gaplessly after uploading. The editing resolution of each bitrate is different, so trackmarks will end up being placed to conform to one resolution during recording, and the moved [requantised] during upload to conform to another resolution [75fps].

At this point, I'm just going to say, "Hmm," because testing this definitively will be fairly difficult [because we can't drop tracbkmarks with frame accuracy "by hand", trusting auto-t.mark isn't accurate either, and relying on t.marks passed by SP/DIF with SYNC.REC on means it's always conforming to 75fps].

Note: I believe this issue may be fixed by software - the software just needs to tell the hardware somehow to ignore the trackmarks

Software fixes are a possibility, yes.

I don't think the best method would be to ignore t.marks altogether [although I have to say - the option certainly would be nice].

I think the better solution [assuming all audio is conformed to 75fps by SS and this is what generates the error in the first place] is to do a quick and simple bit of DSP during combining to omit the repeated sections.

Dumping them during upload could mean breaking gapless burning directly from the uploaded tracks [again, assuming this is where the problem comes from in the first place].

Note that for those using editing software and making their own CD tracks for burning [which is most of us, I would imagine], this will not be an issue, since sample-accuracy is then actually -more- important than CDDA frame conformity.

A possible explanation might be like this:

- sometimes (everytime?) a recorder finishes transferring a track from disc it has its pick-up a small bit behind the next track's mark (i.e. beginning),

- then a command to read the next track arrives from the host and the recorder has to seek back (this can be heard indeed! - seeking does not occur after removing the marks)

- probably reads are performed by blocks and track marks may be placed in the middle of a block and some weird sircumstances prevent the MD unit from addressing within the block correctly. So the Sony engineers simply chose the safe way to overlap audio reads

Basically a simpler way of saying what I tried to say above. [kudos!]

Here's another wrench to throw into the mix:

I have now experienced the "moving track marks" bug while transcoding from WAV files. This one is rather bizarre but comes about from some pretty straightforward reasoning. Hopefully I can say it clearly enough to be understood.

Here's what happened:

I took tracks from a CD that were segued together and edited them to be "single" mixes. I did not care about conforming tracks to exact 75fps lengths because I made the [incorrect] assumption that they would be padded out during conversion to atrac3plus.

I imported the WAV files into SS and converted to a3+... During this process I also manually tagged the tracks; according to the SS database they were all part of the same album, even if the track numbers were not contiguous.

During conversion, and it did this whether I selected one track at a time or the entire album at once, SS attempted to maintain gapless playback between ALL of the tracks .. rather than padding them out to the next full frame, though, it actually truncated the preceding track and included the truncated section at the beginning on the next one.

The end result is that several of the track marks moved backwards. Skipping to the next track would catch a tiny "blip" from the end of the previous one.

Going back into my editor and manually padding out the end of each track with silence to conform to a 75fps length fixed the problem in all instances. Also note that downloading the tracks as PCM did not cause the same problem, so "moving marks" problem occurs during the encoding process.

So - long story short [too late] - SS is moving trackmarks because it's trying to maintain gapless playback after conversion.

The reason I'm pointing this out here is that it does relate to the repeated sections "bug" .. In both cases, SS is trying to force the length of a given track [whether it's uploaded or being converted for download] to a certain framelength. That framelength will probably NOT be 75fps unless you're using PCM, too - the framelength for HiSP is longer, and for HiLP it's -even- longer, meaning the lower the bitrate you encode to, the more the trackmarks are likely to move [to conform to the framelength of the bitrate used].

Final point: what we're seeing as bugs appear to probably be coming about because the SS software engineers are trying to maintain gapless playback by conforming everything going in and out to certain framelengths.

Top Cat - profuse thanks for your input, you've stimulated my brain. Perhaps between the lot of us we can pinpoint what the situation really is, and give a detailed bug report or two to Sony, along with a couple more feature requests [like "do not conform uploads to a given framelength] and fix strategies.

Okay. I'll stop. Someone please try to make sense of all that.

Geez I write long posts.

P.S. I'm trying to devise a simplish way to actually test all this. I'll see what I can come up with. Let's hear it for tone generators.

[dex Otaku]

Final answer:

http://forums.minidisc.org/index.php?showtopic=14499