dex Otaku

I have used MD and HiMD recorders with Mackie mixers a plethora of times. Most FOH Mackies have tape in/out jacks [as RCA connections] on the top of the board for this purpose, and they work great. Other mixers may have dual 1/4" or XLR outputs on their back, in which case you need proper cabling in order to hook up to the 3.5mm jack on your recorder, but otherwise they should work fine. Side-note: if the mixer you're running from has no tape in/out like most Mackies, there is likely a switch for output level [-10 / +4] as well. -10 is the setting you'd want to use with portable MD or HiMD equipment [i've had +4dBu outputs overload a MD recorder before because there was no separate level control, only the main mix to control it with, which also happens to usually be running straight to the PA amps].

I have run into this problem as well. Basically, any "skips" that occur while recording amount to uncoverable write errors, a.k.a. anything recorded after the first skip is a gamble as to whether it will be usable or not. I have seen multiple results of this happening: * the track with the skip in it is corrupted during uploading, and not playable or copyable afterwards * the track with the skip in it is corrupted during uploading, along with all subsequent tracks on the disc, the same as above * the track with the skip will play but not upload, and the problem can be gotten around by the method you described [or using Total Recorder] I have become much more careful since I first realised this was happening [with SS 2.3] so I honestly don't know how much of the above applies to v3.2. Hopefully only the last case.

Thanks for the heads-up. I have not run into this myself, as the first thing I do after uploading is convert to WAV, after which the SonicStage [OMA] tracks are basically there as backups until I've securely backed up the WAV files, after which I simply blow them away. The real lesson perhaps: don't count on OMA as a format for anything but an intermediate stage, which you convert to WAV and subsequently ignore because things like this are likely to happen. Sorry dude.

UMD is in fact not even slightly related to HiMD or MD. UMD is a descendent of DVD. It is a stamped, glass-mothered optical disc. Writeable or rewriteable versions of it will either be dye or phase-change material based, as with existing DVD and CD recordable formats. MD is a magneto-optical format. HiMD is a hybrid magneto-optical / domain wall displacement format that descended [in part] from it. The physical differences [read: total incompatibilities at the physical level] are quite stark between UMD and HiMD. That said, I think it was a bit ridiculous of them to work on both formats at the same time. Sony are, however, a huge company with many divisions doing parallel research with little to no communication between. The two formats are also aimed at completely different markets with completely different usage demands, even if they do overlap in some places.

I was expressing my opinion. If you don't like that, feel free to skip to the next post.

Thanks, ozpeter. It would still appear that the best solution is to avoid combining in SS, and to bump tracks together in your editing software. At the least, this would provide the opportunity to check for the short repeated chunks because the join is done manually. [incidentally - I'm still glad I combined tracks before editing in the case of at least one disc - 6 hours of audio in 485 tracks. TOOOOO much time to do manually.]

Oh? That's news to me - but would also explain the problem I had, since I was recording [30+ hours of material] through the line-in. I must test this eventually. Sounds like a hardware bug to me.

Thanks, greenmachine - I'd experienced the same problem with HiSP, but hadn't used the combine function since then [i.e. hadn't tried it with PCM]. I guess that makes it official, then: Don't use SS's track-combining functions at all.

A note to those of you who read this: SonicStage v3.1 and 3.2 DO NOT COMBINE HiSP CORRECTLY. You are better off simply bumping tracks together in your editor after exporting to WAV, without combining them in SS.

ATRAC/3/plus are just codecs. In some wasy it is quite efficient, in others it is quite plainly not as good as others [hard transient handling is poor in all incarnations, for example]. I never use low-bitrate encoding for anything, really, and nearly all codecs handle things with sufficiently low artifacting above about 200kbps, so really, the question of codec is nearly irrelevant to me. If I had the storage to do so, I would use lossless-packed formats always, or LPCM in their absence. Low-bitrate codecs are for people who can't hear the artifacting or simply don't care. I'm not one of them. Incidentally, the whole gapless issue is not something inherently caused by the codec in use. With the case of audio copied from CDs to mp3, it's caused by one thing in particular: each chunk of audio in the mp3 is of a different length than each chunk of audio read from the CD. Unless the codec can handle audio at the exact framelength of CD audio, true gapless support will not be inherently supported by the format; this can be overcome by several means, however, including metadata in the ID tags specifying the actual length in samples of the track before encoding [which few programs use, still] or simply crossfading tracks [less accurate but still works most of the time]. The important point here is, of course, that mp3 can support gapless playback, it's just that the most common source used to encode from doesn't use the same timing [packet length] as the encoded audio does. ATRAC/3/plus do have an advantage in this case because they are made specifically to deal with audio at 44.1kHz sampling rate, 75fps.. which, interestingly, is part of why it performs so poorly on ringing/pre-echo tests [such as the infamous castanets test]. I, personally, could care less if ATRAC/3/plus survives. It requires liscensing to be used for any purpose, which is the primary reason it never went anywhere - why bother paying Sony for a codec when you can create a better one yourself, or use an open-source codec, or liscense something cheaper? In reality, ATRAC/3/plus are proprietary, closed standards, and that is exactly what will spell their death. Given the choice of codecs available nowadays, especially open-source ones such as OGG Vorbis, WavPack [which has a hybrid lossless mode], and FLAC, the majority of proprietary codecs really should just evaporate from the face of the planet. The open-source sector does just as much if not more R&D in this realm [lame's encoding optimisations being a prime example] to make up for the loss of most expensive, closed, proprietary codecs. And yes, I know that mp3 isn't open-source, my point about lame was that the open-source community have tweaked the mp3 codec way beyond what FhG has.

I always kind of titter when I see tests like this. Aggregate spectrum analysis results when using music aren't really good for much. You would be much better off using sweeptones and complex noise to find where the filters are. In any case, except under the absolute worst circumstances [like a bug in the encoder or decoder], this kind of test actually tells you nothing whatsoever of the actual quality of the codec.

Keep in mind that ATRAC is also used by SDDS for 8-channel theatre sound. I would expect it to hang around in this use at the very least.

Unit: MZ-NH700; MZ-RH10; SP-TFB-2 mics; various other mics; 1 X 1GB disc, 30+ MD80s daily use: as portable player favorite use: soundmarking/environmental recording; documentary recording professional use: as above, also for other location recording, 'wild' foley work alternatives? portable player: PCDP, MP3-CD player, cassette recorder: R-37 MD [friend's]; Nagra 1/4" 1/2-track mono open-reel [friend's]; VHS AFM; Hi8 AFM; miniDV PCM; notebook computer with M-Audio preamp / A/D [friend's]; other pro video equipment of many formats [loans/rentals] request: forget completely about trying to compete with iPod and other HDPs; retask HiMD's marketing, keeping the product alive but aiming it specifically at amateur and professional recordists [to elaborate: market it as a portable recording format, don't even mention playback features at all]; make media more available [1GB discs still not available where I live, though order-able at $14CAD each]; design future units as ultimate recording devices, with playback features as they are but more of a 'bonus feature' than a main purpose; dispose of player-only units completely; make at least one decent home component unit; release data recovery software for HiMD; re-include backward-compatibility; make all units Mac-compatible; make "manual levels with limiting" an available recording mode; include date/timestamping in all models; make simpler software meant for uploading recordings directly to .WAV only [as on Mac]; make Sonicstage or equivalent capable of using any audio format supported by system with directshow filters; intergrate FLAC or WavPack encoding including for recording; develop higher-capacity discs, and offer 24-bit 96kHz recording; WORST CASE SCENARIO for the format: design HDR with flash capabilites as well, 24-bit 96kHz recording, decent mic preamps, and offer MD/HiMD owners the units at cost

"Spoken word" as a subcat if anyone shows interest. Perhaps "Theatre/Spoken Word" or something.

It can display levels while in hold. You just have to set the display to "on" rather than "auto off". It might help to house the recorder in a heavy ziploc bag [transparent or translucent] rather than something made of opaque fabric, too. I do this when recording during rainstorms. Incidentally, re: the unit recording noise from a celphone, I can't record from a plug-in powered mic at all if using the 35ELK remote. The display updates are plainly audible. I have tried using different RF chokes on both the mic and remote cables, but realised that the problem came because the remote's noise [or strong harmonics of it] is smack in the audio band. The placement of the mic and remote jacks [side by side] is a large part of the problem as well. Even if the cables are run in opposite directions, the proximity of their jacks/plugs is enough all by itself. For myself at the least, using the remote when recording with a unit-powered mic means audible noise. Unbalanced microphone cables are basically antennae for all kinds of EM noise. The shorter the cable, the better. In the case of plug-in powered mics, the noise appears to rideon the bias voltage getting to the mics, making it audible. This is related to the problem with trying the record with plug-in powered mics while the unit is plugged in with an AC adapter [both my RH10 and NH700 do this; loud harmonics of 60Hz from the power lines]. d.

the wimp9 pack can be found on microsoft.com and might even be in the downloads section here. Install it first, then try SS3.1.

Try some recording. Do some tests that you can junk. Chances are you'll be happy with the results you get.

right click on the track in your library after uploading, select "save as WAV". This is assuming you're using SonicStage 3.x.

What I meant my 'amp' in this usage is the amplifier that leads to your speakers. This includes a boombox, portable speakers, jacking in to a car stereo, &c.

Points taken. Thanks for the correction.

Thank you for stating this so we didn't have to. I've been watching this thread with both anticipation and trepidation. I have no desire to stifle discussion, but I am concerned about the legal ramifications of our openly discussing what amounts to the reverse-engineering of patented algorithms, which in itself is an other issue on top of what you've mentioned above.

This makes sense, as the pinnae "shape" the sound differently as it comes from different directions. This is integral to what I'd call the binaural effect. Part of the purpose of your pinnae are to focus the sound coming from different directions in different ways; this includes tiny alterations in phase and level that are different from every direction at every audible frequency. The 'average' of parts of this are what give us information like the Fletcher-Munson curves. Those differences caused by [among other things] the pinnae are central to how we perceive direction and distance, depending on the brain's ability to differeniate between the same source sounding different at each ear. This is much like the aural equivalent of how binocular vision works. I believe it was on Etymotics site that I read the notes about "made for binaural listening". If I have time I'll go looking for it again. It boosts the -reflection- of treble coming from in front of you. You're refocusing the sound is what you're doing, just like cupping your hand behind your pinna[e] is much like using a parabolic mic [your hand is the parabole]. Looks like a listening/recording test is coming up.

I don't know when I noticed it [it would have been sometime during the first day I had my NH700], but as with many things it's become so ingrained that I don't think about it at all any more.

My main media are: For portable listening - HiMD For general storage/backup - DVD-R [knowing full well that these discs likely won't last] For critical backup - DVD-RAM and CD-RW For distribution - CD-R For posterity's sake .. with MD/Hi-MD... * The vast majority [likely 98%] of my portable listening collection is in HiSP [with the rest being MP3] * I will occasionally [okay, rarely] hand an editing project back to someone else in LP2 from SS * I will also on rare occasion make an actual SP-mode MD for someone who can only use that format * now that I have an RH10 my short-term compilation discs are almost exclusively made up of MP3s; albums needing transcoding [from disc images] or ripping are likely to be HiSP, though single tracks I'm more likely to use MP3 with because tags between formats are handled properly by Fb2k * I have never made a PCM copy of anything for portable listening * I have only one album ripped [60s classics in mono, the CD itself is not of great fidelity] in LP2 * I have never used LP4 or HiLP 64 or 48kbps for other than testing purposes, and plan never to use any of them for other than testing purposes; they all sound like absolute garbage to me; SS's LP2 encoding is also garbage to me

Ah. Yeah, I've never heard the term used here. That doesn't mean it's not, of course - it just means it's never mattered enough for me to notice.