dex Otaku

The only type of playback that will likely be passed through the MD is linear PCM. I could be wrong on this, but I have reasons to believe it is the case: Any PCM going through the unit will be resampled to 44.1kHz, which means, since -all- DVD audio is 48kHz, -all- PCM audio from DVD [or satellite receivers, &c.] will be resampled. [For that matter, all audio going through the deck will be resampled, including 44.1kHz streams]. AC3 [aka Dolby Digital aka ATSC A/52] DTS, and MPEG2 [audio] soundtracks *should* not pass through the deck at all. The deck has no idea what to do with streams tagged as other formats, and in the case of DTS [which appears to any non-DTS device as PCM] the resampling process will completely destroy the stream, passing only noise out the other end. Further, PCM soundtracks on DVD are actually pretty rare. Most stereo DVDs use AC3 audio. That said, many DVD players with digital outputs will convert to PCM stereo for compatibility's sake. Consult your player's manual. Satellite systems and digital cable boxes will likely put out either AC3 audio or PCM stereo, and may also include an option to convert to PCM stereo like some DVD players do. The bottom line, though I'll say again that I could be wrong about passthrough, is that only PCM will likely make it through without being destroyed [or simply not working at all]. If you want to hook up a deck so you can record from TV audio, I would suggest simply using the optical out of the video processor to the deck, and the coax out to your AV amp. This would permit using both simultaneously [assuming the stream coming from the av source is PCM] without having to rely on converters or passthrough modes on any device, or having to worry about leaving PCM conversion enabled at all times [thereby sacrificing surround formats].

Ah, well. I didn't know you had a NH600D. SB's one and only function is ripping CDs. The reason so many of us like it is because it's designed for that one purpose, and it does it well. I can't foresee SS being modified further to support this. In fact, I hope they don't modify it to support this. It would be great if they made another standalone app to do it, though. There is obviously demand from users for the ability to timeshift, for example. Otherwise, though this might seem rude, all I can suggest is - if you want something to record on, buy a recorder.

All I can suggest is formatting them with a non-downloader HiMD model, then.

They're not distortions of the truth; they're my opinion. Nothing more, nothing less. I do understand your frustration, but could also point out that you could do timeshift recording with your computer, or any HiFi VCR [AFM audio with a decent VTR exceeds the quality of the source you're recording from]. Not saying that these are actually better options for you, simply that they're other options. Of course, your desire is to upload, so the VCR doesn't help with that, but timeshifting with your computer seems a pretty simple solution to all of your problems, from where I'm standing. As for a HiMD deck, my opinion there [and I sincerely hope to be proven wrong on this] - Sony's view is likely that the market is simply too small to justify the deveopment and manufacturing costs. Given the physical size of decks, shipping adds to the incentives for retailers not to stock them even if they did exist. Given that, mail-order and online sales would probably be the only feasible route to market them, and the cost would either be swallowed by Sony [at a probable loss per unit to keep prices low enough to actually interest anyone] or directly by the customers [making prices unreasonable and unreachable by many if not most of the customers who would want one]. I have never seen Sony themselves state it so, but I would like to point out the myriad users such as yourself who have realised from experience that it can't be done. That seems pretty unequivocal to me. I believe it was The Low Volta or perhaps A440 who put it best: netMD's DRM relied upon the fact that uploading was impossible; I agree with this - the inability to upload was an inherent part of netMD's design. It was not an oversight or an accident. They made it that way on purpose. That said, and to repeat myself again - given the current state of DRM with SS and HiMD, Sony no longer have any excuse for not providing the ability to upload MD/LP recordings. I sincerely hope they include this functionality in any future HiMD models, but that is yet to be seen.

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].

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.

Um. That WAS part of the test I just detailed. :*) 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].

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

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: 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.]

No, no, no, and no. It begs the question, though: why not just record on the HiMD itself, and upload a copy to SS afterwards?

There are two possibilities as to why this happened. First is that you had the recorder in netMD mode. It doesn't sound like this is the case. Second is that you had previously-recorded audio on the disc already, in a legacy encoding format [MDLP modes - SP, LP2, LP4]. If the legacy MD you pop into a 1st-generation HiMD already has MDLP audio on it, it will continue recording to the disc in netMD mode. Whichever was the case, your solutions are either to use a MDLP deck with optical out feeding an optical in on your computer/sound card, or to go the old-fashioned analogue route. There are stickied topics on doing just this in at least 3 places on the fora here [such as the netMD forum], so please look there for advice. The bottom line is that if your recording was made in netMD mode [i.e. legacy MD/LP], there is currently no way to upload that audio with SonicStage. The analogue route will be your most likely solution.

Thanks for the link, bjsilva - it's a good one. [Finally, someone talking about normalising in a way that I agree with! heh.]

This is probably caused by whatever you are using as your system [directshow] MP3 codec. SS appears to be allergic to certain codecs, so to speak. Once again, I will decline giving detailed advice on how to fix this, though. There are many possible problems/solutions, some codecs don't even show up in the relevant control panel [sound and audio devices, under the "hardware" tab, double-click on "audio codecs" in the list], and others do not respect codec priorities even when you set them manually. Some malware also install a broken codec which replaces the one that comes with WiMP [iIRC]. In any case, the general advice is to check what codec you're using, and if it's being a problem, dump it for something else. If in doubt, look around online for the actual FhG MP3 codec, it worked fine for me before I switched to using FFDshow.

As I have not encountered any of the downloader-only models myself, I made the assumption that the 600D would have the same menu functions as the rest of the line. My apologies. If SS won't initialise the disc, perhaps your only fix for this is to use a recorder [non-"D"] model to reformat the discs. That is assuming that you have a Sony shop nearby, or know someone else with a recorder [erasing the discs with a netMD or earlier model should work just the same, btw]. What were you doing with the discs when they went belly-up? As I've suggested to other users recently [having rarely run into the same problem myself], sometimes if a disc reports an error immediately after downloading to it, removing all sources of power from the unit, then plugging back in [basically cold-booting the unit] has "saved" it for me in the past. If that doesn't work, you might also try the same but having removed the disc in the process. Last time I ran into this [roughly a week ago] I did both and the disc read fine afterwards.

Also: you don't have to have the unit paused to change levels. You do have to have it paused to enable manual levels, but once that is done, you can adjust on-the-fly while recording. This is indeed one of the majour annoyances of Sony's product line [and is extremely old news, nearly all of the product reviews here and elsewhere would have warned you of this fact], but at least they have enabled adjusting levels on-the-fly. Many previous MD models could only be adjusted while paused. As to the rationale for things working this way - it probably comes from interviewers using equipment on location. You'll note that the mic preamp sensitivity is a "remembered" setting [as many broadcasters will set the mic preamp to high sensitivity and always use AGC - fidelity is not their goal, getting the recording is], while manual rec levels is not; the idea being that the second you hit record, the unit is recording, and AGC is handling potential problems with levels right off the bat. No, it's not perfect. It is, however, part of a "quick access" solution. Also, AGC is relatively, well, idiot-proof. As the general usage profile of HiMD [and MD] is changing, IMO, to hobby recordists, Sony might hopefully [and finally] cave to our demands that this be a remembered setting between rec-stop cycles.

http://forums.minidisc.org/index.php?showtopic=10621 Scroll down to "MP3 playback test." eriktous is correct in that this is old news [it was known within a week of the release of HiMD's 2nd generation last year] but that graph at least shows exactly what it's doing.

Is there an option under "options" for MENU MODE, to switch it to ADVANCED?

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. 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... 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]. 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. 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.

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].

in the menus: File -> import -> scan folder this will let you add your existing media to the library. Then go to: tools -> start file conversion tool That said, if your existing tracks are readable by SS [i.e. they're WAV, MP3, or WMA files] it might be easier to just convert them on the fly rather than having to [first] duplicate your entire library [and second] have to add another pass of loss to every file already encoded in a lossy format. Point being: for listening on your PC, you should maintain your current library of [hopefully] first-generation encoded tracks, and perhaps convert them as needed when transferring to your player. If the added pass of loss doesn't bother you and you have lots of space to invest in duplicating your entire existing library, then go ahead and encode everything as you wish, of course. Side-note: The reason "importing" your existing tracks takes so long is primarily because SS has to read all of their tag info and assimilate that information into its own database.

Enter the menu, go to EDIT go to ERASE select ERASE ALL or [i believe advanced menu mode has to be turned on for this] Enter the menu, go to FORMAT the rest should be self-evident. There should be no need whatsoever to enter service mode just to erase a disc. You say that SS doesn't recognise that there's a disc in the unit, though? Does it do this with all discs, or just the one? Does it recognise that your 600D is plugged in but not that there's a disc in it, or does it not see the unit at all? correction: for the 2nd one up there, Enter the menu go to EDIT select FORMAT

Assuming we're talking legacy MD here - what encryption? There is no encryption used on MD.

I've seen this happen, and have so far been able to save the disc in question by removing it from the unit, removing all sources of power from the unit, then plugging back in &c.

No, I don't think they do - and that's exactly the point. Because they don't care, we have to. You obviously don't, though.

SS is not customisable in this way.