dex Otaku

I haven't had any problems with HiSP, however - people have reported bugs in how HiLP splits and/or combines on 1st-gen units themselves, so perhaps this is a problem inherent to HiLP.

It depends on how recently it was packaged. In any case, I'd skip the discs included with any hardware I buy and go directly to the company's website to get the most recent stable drivers and software.

Yes, my answers will be slightly different from the others. Reformatted MDs write at 4.37Mbps; HiMD 1GB discs write at 9.83Mbps. To give a basis for comparison, a CD reading at 1x runs at just below 1.5Mbps. You can count on an iPod transferring data at well above 10x the speed of HiMD, basically as fast as any USB or firewire hard disc will run at. In more real-world terms: it takes 30-60 minutes to fill a 1GB disc; it takes about 10-15 minutes to fill a reformatted MD80. The more tracks you are transferring, the longer it takes as there is more disc activity. For gen.1 HiMDs - assuming you mean MP3s, no. You have to transcode the audio to one of the atrac/3/plus variants in order for it to be playable on the units. As with all things, GIGO - if the MP3 you're transcoding is crap to begin with, it will end up being worse. On the other hand, if the MP3 you're transcoding is of good quality, chances are you won't notice a big difference with HiSP. IMO, HiLP 64 and 48kbps always sound like crap, even straight from a CD source. For gen.2 HiMDS - yes. You can download MP3s with SonicStage without transcoding at all. Assuming the files were tagged properly in the first place, yes. SonicStage still has the tendency to mutilate tags sometimes for no apparent reason [like ignoring track numbers]. SonicStage is capable of dealing with almost any non-DRM'd MP3. There can be problems with weird bitrates, files that are not at 44.1kHz sampling rate, and VBR files, and these problems can be exacerbated by having multiple system codecs for MP3 and such. For all intents and purposes, there are no limitations, though. As long as the MP3 itself is "standard", i.e. it is not encrypted for DRM or anything [in which case it wouldn't play on anything other than the device or software it's been made for anyway] it should work. I have come across very few MP3s that don't download correctly straight from SS, being transcoded to HiSP for my NH700. Most of the problematic ones came from specific encoders that seem to be the root of the problem. I have never had difficulty with VBR files, myself.

SP = 292kbps; HiSP = 256kbps. I wouldn't call that "much higher" in any case. SP is more mature than HiSP, but in all honesty, I can't find any serious faults with HiSP under most conditions. That is keeping in mind that both are lossy, and both suffer the same weaknesses [such as pre-echo and ringing problems with extreme transients].

I tend to use PCM mode for music and environmental [i.e. ambient sound] recordings, and HiSP for voice. I have fallen back to using HiSP for music recordings on HiMD-formatted MD80s when I expect a show to last longer than 90 minutes. I have not, so far, ever made a recording on my HiMD that had noticeable artifacts, even after editing and subsequent re-encoding to [lame --alt-preset standard] MP3s. Certain recordings [especially ambient] have really odd-sounding artifacts after only 2 lossy compressions, but again, most people don't notice them even if I do. Note that I find LP2 unacceptable for anything but first-generation recordings encoded by hardware. I find SS's LP2 encoding to be unacceptable in almost all cases I have tried thus far. I have been using my one HiMD [1GB] repeatedly since getting my NH700 last August without a single problem that seemed disc-related. Note that recently I have been recording, on average, a couple of hours per week [in PCM mode]. I have not experienced dropouts or anything of the sort. Other users have reported defective discs, so keep in mind that your mileage may vary.

2005-11-13: It's been a while since the original version of this was entered or edited, and it's about time it was updated to reflect the board's discoveries since then. Both others and I have discovered the hard way that when making line-in recordings, HiMD recorders' auto trackmarking function [which can not be disabled] causes short repeated sections in the recording where track boundaries occur. Actually - sometimes they aren't there at all, sometimes they're only a few samples in length, and sometimes they're as long as 1/3rd of a second [going by my recordings]. This caused me to revise my suggested method for gapless burning, since the old way I had detailed involved using SonicStage's track combine function, which in the case of line-in recordings will be completely unreliable and cause much more grief than simply dealing with individual files in a non-destructive timeline editor such as Audacity, Audition, or Vegas. Cheers, D. ------------ There is only one sure way to maintain completely gapless recordings when burning CDs, regardless of what your original source is: edit all contiguous tracks as a single file. The reason why: Audio CDs store data in sectors that are a specific length. To fit in that sector size, audio is stored at 75 frames per second [or 588 stereo samples]. Gapless playback can only be maintained if every track on the CD you are burning is an exact length in frames, not samples.. Rephrased: you can NOT edit CD layouts or the audio going into them [if it must remain gapless] with sample accuracy, ONLY with frame accuracy. Any attempt to run two tracks together seamlessly where the first track is not an exact length in frames will fail. Some CD software [such as newer versions of Nero] will automatically crossfade tracks to avoid this, but this should generally be avoided; it may work, but the point is being missed entirely - if you're writing an original CD layout, especially a master for one of your own recordings, the layout should be valid [i.e. redbook standard-conformant] to begin with. Anything else is simply asking for trouble, especially if you want to distribute your recording in any way. Most other [and all older] CD writing software will simply pad the end of a track that isn't a full length in frames. This is where glitches come from. Note that both MD and HiMD conform to the same framelengths used by CD-DA [audio CDs], and depend on tracks being exact lengths or rounded to the same 75fps to maintain gapless playback. How to do it: The only 100% completely reliable, it-will-never-fail way to write gapless CDs from gapless sources is to edit all contiguous tracks as if they are a single file and add track marks in your burning software later. Note that you can carefully split files into single tracks and maintain "gaplessness" throughout as long as the tracks are kept to exact lengths in frames. I do not use and advise against this method because it's very easy to screw up if you're not careful. A change in the length of a track by a single sample will usually introduce an audible glitch in your recording. Here is my current upload/editing procedure to give you an idea of how I do things: <blockquote>* Make my recording * Upload with SS * Export all tracks as WAV in a folder called "unedited" * Do my editing in a non-destructive editor such as Vegas, Audition, or even Audacity * Render the edited layout to a single WAV file * Add track marks in my CD authoring software * Burn my CD to CD-RW * Rip it as a WAV image with DAO cuesheet using EAC [making sure EAC is set up for correct read offsets] * Convert the WAV file to FLAC with embedded cuesheet * Add whatever extra tags are required, including production notes, to the FLAC image</blockquote> I never, and I repeat, NEVER have problems with gaps, glitches, or anything of the sort, and my end result is something I can burn directly from Nero for distro purposes, including CD-Text labels and all. I can also drop the FLAC disc image into programs like Foobar2000 and it will automatically recognise the embedded cuesheet with full track information and simply play as though every track were a separate file - and gaplessly! Procedure in detail: When I make recordings, the track marks on the HiMD itself are basically irrelevant to me as anything other than a guide. Far more important than marking tracks is using group recording mode, where each time you hit stop and start recording again, the unit creates a new group. With most of my recordings, each group created represents the beginning of a single session - i.e. one period of contiguous time - for editing. 1. Upload your tracks. If you need advice about uploading, see the uploading FAQ. As an addition to the advice in the uploading FAQ, I find it helps to include the group number and track number when naming tracks on the HiMD or in the SS library. This makes it easier to identify what parts should be combined and which shouldn't. I title each group with the date, group, and track within group - before uploading. This ensures that tracks are meaningfully titled and that files are meaningfully named when you export them to WAV. An example of a list of tracks in a single group I'm going to upload would be: 2005-11-13-test recording-g101 2005-11-13-test recording-g102 2005-11-13-test recording-g103 The next group would be: 2005-11-13-test recording-g201 2005-11-13-test recording-g202 &c. .. This makes it obvious which parts belong together, not only in order but in terms of when they were recorded and what is most likely to be contiguous on the original disc. Naming tracks *before* upload means that SS will name the actual files with whatever title you've given them, which can reduce the hassle of dealing with SS's default naming system. 2. Export your tracks to WAV. This is simple is SS 3.x - just select a range of tracks in the library, right-click within the selection, and choose "Save in WAV format..". I'd suggest putting the files somewhere meaningful. Following the above example, I'd make a folder called "2005-11-13 - test recording", then make a subfolder in it called "unedited", and dump the files there. Restated for those of you who can understand paths: I'd put them in "d:\2005-11-13 - test recording\unedited". For those of you who use FLAC and Cool Edit / Audition, you might want to convert to FLAC now. For speed's sake, I do all my editing with straight PCM files, just to reduce a bit of overhead. One advantage to using the FLAC method if it's available to you is that you can tag FLAC files, whereas there is no strictly-adhered to standard for metadata with WAV files. This means you can't add information to WAV files that more than a few programs will be able to understand. 3. Backup the tracks in case of catastrophe. It takes space and a bit of time, but can save your rear if you do any destructive editing, whether on purpose or by accident. Making a second copy on your hard disc is fine if you trust your hardware, and burning a DVD- or CD-ROM is another option. I rarely make backups this way before editing any more because I do all my editing non-destructively. In any case, the originals uploaded into SS become the definitive pre-edit master - you can export as WAV again if need be. 4. Drop the tracks into your editor's timeline in order, then make sure the ends either meet or overlap correctly. Be sure to check that tracks that appear to be bumped together in your editor actually are - and if your recording was made with line-in, make sure that possibly repeated sections are either crossfaded or intercut correctly. Zoom in at junctions, make sure tracks meet end-to-end, and even zoom in "vertically" [amplitude-wise] if you're editing line-in recordings - you can usually see those brief repeated sections to edit them out. 5. Edit your audio. The important thing here is for your assembled timeline in your editor to have no gaps in it. If you can play it gaplessly in the editor when you're done, then everything is going right. An important point to note is that if you edit an entire album as though it's a single file [i almost always do], you can apply effects such as compression, normalisation, &c. to the entire mix from beginning to end. If you, like I do, tend to not alter your record levels once you've started recording [or at least, after the first track or so], your entire recording then has a consistent reference level; you just fix things to the first track [or the point after which things don't change] and apply processing to the entire album in one go. The extra time it appears to take to process an entire album is usually far less than the amount you can waste on processing each track individually. 6. Render [save as.. in some editors] your edited audio to a single WAV file for each section that must be contiguous. I usually render an entire CD as a single WAV file. For those of you who might be using Sony/Sonic Foundry's suite of editing apps, you can set Vegas or Sound Forge to follow 75fps and add regions which CD Architect can convert dircetly to tracks later. Whether this works between other applications is iffy at best, but may be worth trying if you want to. For really simple editing jobs, CD Architect can be used directly with the original WAV files exported from SonicStage, as it basically is a timeline editor itself. Both Vegas and Adobe Audition can be used to make a CD layout and burn discs directly from within themselves, as well. How you do it depends on how you prefer to do it. I tend to do my editing in Vegas, then my CD layout in CD Architect, because each tool is optimised for its own purposes. The one thing CD Architect in particular lacks is CD-Text creation [which it lacks because CD-Text is technically not redbook compliant and CD Architect is made for making fully-compliant masters]. 7. Import the rendered WAV file into your CD authoring software and manually add track marks. Most CD authoring programs that are even half worth their salt will allow you to insert track marks in a large file, or split a large file into tracks. CD authoring software always automatically conforms to 75fps [they have to, otherwise they're not burning audio CDs], so there's no worry about gaps or glitches. Programs like Nero allow this. The slowest part of doing so is waiting for Nero to draw the waveforms for your tracks. Once this is done, navigation is usually pretty quick. Tracks are usually fairly obvious on a visual timeline; in the case of continuous mixes like DJ mixes, it'll take some shuttling back and forth to find where you want the markers to be. That's basically it. The point behind all this is, once again: if you split your audio up into tracks before putting them into your burning software, you likely will end up with glitches - unless you know exactly what you're doing, in which case you don't need this howto. Cheers and happy editing.

I've already posted the solution several times [including twice tonight alone]. I am going to go looking for my original thread on the subject of gapless burning, and pin it, as people appear to be experiencing this problem a lot when there is no need for them to.

Sony's notes about "original installed OSs" are essentially their way of saying "if you built it yourself, or if you changed anything, we won't support you." That has no actual bearing on how the software works, though. I, for one, would NEVER use a preinstalled OS on ANY computer, because factory installs are usually so completely unreliable.

There are several threads in which I have mentioned before that the only truly reliable way to do gapless editing and burning is to work with all contiguous tracks as a single file. When using Marcnet's HiMDRenderer, you will -always- experience minor variances in actual track lengths with its output, meaning you have to edit all track transitions. I have to be honest, and this isn't a slight toward marcnet by any means, but since SS 2.3 I've found the reliability factor has increased significantly. I don't use HiMDRenderer at all any more. With SS 3.0 and later, simply right-clicking an uploaded track in your library and using "Save as wave" is far more accurate in terms of track lengths than HiMDRenderer is [marcnet would not dispute this, as he has pointed it out himself]. The trick is to combine all contiguous tracks using SS's combine feature, then add trackmarks in your burning software. This totally avoids having to edit track transitions in any way, and fully maintains gapless editing and playback as long as you keep things as a single file through to the CD layout stage. I have only had SS crap out once during a track combine, and it was caused by something else that was running that brought the system to its knees. Note that combine works best with only a few tracks at a time, because it takes time to do - SS can appear to be locked up during combines when it's actually working just fine. If you must combine a load of tracks all at once, I advise walking away and letting it do its job. If you interrupt the process, it will damage the tracks it has combined up to the interruption, rendering them unplayable in your library. If you don't believe me on these things, I have been recording a lot of things in the past few months and have been using this method since I got my HiMD last August. In the past 6 weeks alone, I have recorded, uploaded, and edited at least 20 hours of recordings, the majority of which were completely gapless to begin with [usually 40-100 minutes in length]. I never experience problems doing things this way [and haven't since I decided to stick with "one big file, internal regions/trackmarks" method around 2000]. As I just said in another thread: use the combine function, and use it well. There is no need to combine tracks on the recorder itself, which is basically just wasting your time playing with the fiddly little buttons to do something that SS can do automatically. As far as SS's annoyances in how tracks are sorted, &c., my advice is this: Don't use SS to play or in fact do anything else. Use it as your reference library ONLY. Upload tracks, immediately combine the contiguous ones, and then export them as WAV to deal with them as you wish. I no longer use SS for anything but uploading, combining, and exporting [as well as downloading MP3s]. Anything else is basically a waste of time with it. Hint: make sure that the option to record using auto-grouping is on. Generally speaking, I combine all tracks within a group, then export.

I regularly use time mark to divide large programmes into chunks. The first thing I do after uploading is use SS's combine function to recombine all obviously contiguous tracks. I never get gaps, I never get dropped samples, and if anything catastrophic should happen during an upload the largest piece I will be missing is the length of the time mark setting. In fact, I have never experienced gaps/lost samples, whether using manual track marks, time mark, or auto trackmarking with the line-in. The trick to avoiding this is SS's combine feature, IMO. The likely reason this is happening is that all discrete-transform [fft, mdct, etc.] lossy formats use frames that overlap. This is part of why MP3 is not gapless [aside from its using, by default, a framesize not related to CD-DA's 588 stereo samples/frame, aka 75fps], among other things. SS is slightly smarter than you think, as is how all of the atrac variants are set up. Combine and divide are there for a reason. Use them, and use them well. Dont', and do so at your peril. ozpeter: MPEG2 video [and almost all lossily-compressed formats] is/are difficult to edit with because they use keyframes, which happen either at a maximum interval apart [like 300 frames by default for most mpeg4 codec variants] or as automatically detected at scene changes. Audio recording does not work the same way, and the problem being experienced here is completely unrelated. matheis: as I've pointed out before, the only method that retains true gapless editing/burning/playback is to edit all contiguous tracks as a single file, inserting trackmarks with your CD burning software, not by dividing them before or during editing.

I back up all my original and edit copies using FLAC and DVD-R. I also back up the distro copies using FLAC and DAO cuesheets for quick CD burns. FLAC is free, multi-platform, can stream, is frame-accurate for positioning [most lossless formats aren't], and compresses at least as good as and often better than Monkey's Audio, which admittedly has a much nicer interface included with it. I'm a nerd, though.

Yes.. I didn't deny that it would work with an existing install of SS that has the rights info for those files, however - As long as you maintain the same database that the tracks originated from, they will work. If you do a clean install of SS with a fresh DRM database, you can't restore the tracks. This is exactly the same as installing on a second machine and trying to restore the files to that db. It simply won't work. So - as far as being a backup, this method is unreliable unless you maintain the same db on your install of SS. Maintaining that db through a full re-installation means using the SS backup tool, which already backs up the tracks, though they can't be restored individually.

The error: you can't import an OMA file like that if the database has been erased. Another way of putting it: you can only re-import files while they are currently listed in SS's database. This makes OMA files basically impossible to back up one at a time [the SS backup tool does work for the whole library, though] because the rights info doesn't get transferred with them.

Please note that "software" in the context I used referred to anything that can be played on hardware; music discs are software, tapes are software, &c., or at least, their contents are. And yes, Hi-MDs could be mass-produced at great expense, but the discs would be erasable because HiMD relies on DWDD, as has already been pointed out. Cassettes were popular, yes, but you can mass-duplicate cassettes at many times normal speed. HiMD would have to be written at its maximum write speed, which depends on how fast a laser can heat the write layer and how quickly the write layer can cool down afterwards. Trying to make it go above a certain speed would just write garbage data to the disc. I can't imagine how expensive pre-recorded HiMDs would be. Aside from the currently high cost-per-unit for manufacture, the equipment and time required to do the job would inflate retail prices per unit to probably the $40 range here in Canada. If you think that's ridiculous, consider how much it costs to mass-produce CDs - very, very little, and yet they retail here for $20-25CAD a pop, once you take into consideration the artists' cut, the distributor/record company's cut, packaging, shipping, and retail markup. HiMD is impractical, at best, for mass-production. It's not impossible, but it would be very expensive.

How? Why? Yeah, I could really see popularity for the units skyrocketing if they relied on a media format that can't be mass-produced. I'm sure the fact that no software would then exist for them [or that the software would take aeons to copy at approximately 30mins per single full 1GB disc, which customers would then accidentally erase left right and centre because most poeple are daft as fenceposts] would really increase their popularity.

A simple answer as to why PSP isn't Hi-MD based: Hi-MDs cannot be mass-produced. UMD, being derived from the same manufacturing techniques used with CDs and DVDs [stamped discs], are easily mass-produced. Hi-MD is, basically, a rewritable format only. They cannot be mass-produced using glass masters et al.

The first dot [the centre] is the -12dBfs mark. The second [top] dot is the 0dBfs [actually, just below and up to 0dBfs] mark. The bottom segment is around between -35 to -40dBfs on my NH700. Generally speaking, the centre mark is good to average at if you know that you're recording isn't going to suddenly jump to a much louder volume. You also don't want to reach the top segment of the metre, as that's where distortion begins. For loud / really dynamic material, peaking around the centre mark is cool [with a lower average], that way you know you still have about 12dB headroom to use. I usually try to record with average levels around -20dBfs. That gives plenty of headroom and also usually keeps all wanted signal well above the mic preamp's noise floor [this varies depending on what mics you use, their sensitivity &c.]. By comparison, note that EBU broadcast equipment uses -20dBfs as the "0dBVU" mark .. I believe North American [sMPTE, likely] equipment uses -18DBfs. If you're using AGC [not manual levels] then you have no control over any of this, so the point is entirely moot.

I have used MD for syncing to video in the past and it works very well for non-timecode equipment. Generally speaking, you can walk around with a recorder in your pocket [i do this regularly] without having to worry too much. They [also generally] won't stand for running, or if you have a really jolting walk perhaps, but if you're used to walking to shoot video or film with a hand- or shoulder-held camera, you likely know how not to jolt the equipment you're carrying. I'm going to be giving a workshop this summer to the local film community on how to do ad-hoc sound for film [i.e. with consumer or prosumer non-timecode equipment]. I'm looking forward to it. btw, if you want absolute shock-resistance, flash-based recorders are the way to go. Do a search on the board here, you'll find a few threads about Edirol and Marantz equipment that is generally more expensive than MD or HiMD, but have advantages of their own - and in the case of the Marantz, is basically pro equipment in the sub-$1000 range.

I see a few recordings in the archive already that are from groups that I seriously doubt allow live taping, let alone redistribution of personal tapings. Please note that the administrators and staff of this board will not be held responsible for any copyright violations incurred by our users. You are responsible for what you upload. Please make sure that you have permission to post recordings before doing so. Some bands have clear taping policies that allow "bootlegs" to be distributed without legal consequence [unless sold, at least]. If you are unsure of the copyright status of your recordings, either: * check with the band themselves, or * check with the band's publicist, publisher, and/or record label Most band's publicists or publishers can be found through their record label, if they are carried by a label. Smaller labels often are the publishers and publicists as well. If in doubt, check first. Copyright violations such as posting unpermitted live recordings can carry heavy financial penalties, as well as the possibility of jail terms. Again - you are responsible for what you upload.

You ripped these from the CDs to begin with, right? Why not skip the added generation of lossy compression and rip them right in SS, or better yet, transfer them straight from the CD to your netMD using Simple Burner?

This is what I use FLAC Frontend for.

You should be able to rent a DAT deck in the Boston area from an audio or film supply house. I don't live anywhere near there, but that's where I'd look in the nearest centre to where I live, and there are likely [at the least] hundreds more such places in the greater Boston area than there are in Winnipeg. DAT machines tend to still be expensive, so renting one for a few days to just leave running your dubs is probably more effective and cheaper than hiring time somewhere or hiring someone to dub tapes for you. Otherwise, I'm with bobt on this - if you can afford to purchase one used and then resell it, it might be worth doing. Whether you go the DAT -> computer -> HiMD route or simply DAT -> HiMD depends, I'd say, on what you need to do with the recordings. Considering the nature of HiMD and the flux the format seems to be caught in [adding non-backward-compatible functions, and removing backward-compatible function with every generation, and the possibility of larger media in a few years making the 1GB discs obsolete] I would avoid using HiMD as any kind of archival format, as you are likely to find your discs becoming unusable in less than 5-8 years. [Let the future come back and spank me for making a prediction, now.] I, personally, would go the DAT -> computer -> HiMD route, because the computer stage would enable backing up to other formats that are likely to still be usable for a longer time than HiMD will be [i.e. CDR, CDRW, DVDR, DVDRW], even if CDRW [and DVDRW? I need that answered..] is the only format that suggests usability for archival because of the questionable longevity of dye-based WORM formats [CDR et al]. Also, having the audio already on a computer would ease the process of converting to multiple formats at once, including MP3 [MP3 CDs are great for use with most modern DVD players], FLAC [a lossless-packing format that is excellent for making mass-backups to data CDs or DVDs, which are far more reliable than audio CDs], netMD and HiMD.

The major differences as I understand them are that: * 2.3 and newer are far more stable * [though this doesn't apply to netMD users] Hi-MD uploads aren't botched regularly * 3.0 and newer have far better playlist creation tools * many slight interface differences between 2.x and 3.x [2.0 -> 2.3 isn't that big a difference] * 2.3 and newer recognise devices faster when they're connected [people have reported this, though my experience is actually the opposite; 3.x is slower at recognising my Hi-MD than any of the 2.x series were] * minor codec improvements with each revision [2.1 -> 2.3 has been reported by several as noticeably improved, though I can't tell any difference with LP2; to me it still sounds like absolute poop with 90% of the content I've throw at it] Ripping directly from CD to MD is done by Simple Burner, not SonicStage. As a netMD user, the things you're likely to gain are added [though not perfect] stability, and a slight improvement in the LP2 codec [see above].

In data mode [i.e. dropping files on the drive from explorer] HiMD acts exactly as any USB mass-storage device. You can put any files of any type there, same as on a thumbdrive, hard disc, &c. - and copy them off, same as from any of those sources. DRM only affects tracks writen to HiMD as audio.

While I can't say specifically about the RH10... If the 2nd gen units use the same transport mechanism as the 1st gen units do - my experience with my NH700 is that it's actually louder than any previous model MD recorder I've ever used. That said, it's not actually that loud, but if you're trying to do field recording of very quiet sounds, it helps to: * as skradgee said, keep the mics as far from the recorder as possible [using a 2m / 6' extension cable should work with most mics] * put the recorder in or under something that can obscure the noise when you don't need access to the controls * use a blank disc or a disc with no fragmentation [i.e. no deleted tracks] when recording to reduce seeking during the process