dex Otaku

With the most recent version of SS naming, yes, this is the case. I am too well-accustomed to developing elaborate workarounds, it seems.

Even this isn't necessarily true. Any mixing [overlapping audio in different tracks], crossfades, fades, volume changes, EQ - any signal processing at all, in other words, induces some error in the signal [hence the final stage after processing usually being dither]. I suppose it depends on what you mean by loss, too, though computational/rounding errors cause some distortion and lower overall SNR, which I'd consider a form of loss, though certainly not the same as lossy compression artifacting.

It seems the point got missed entirely, by everyone. Point about titling the tracks, even if it's just with a simple "0101" group group one, track one, is that you can always tell they're in order. Period. It really doesn't matter that you use auto trackmarking to skip quickly between sections. What matters is keeping the sections in order, and your being able to identify them as being in order. SS's current default naming scheme, for short tracks that upload at a rate higher than one track per minute, will result in duplicate track names. Unless you think to enable the column for "time/date imported" and sort by that criteria [the only one that will give proper track order without titling files distinctly], there is no way to keep them in the correct sort order. Ergo, title the tracks distinctly [every track title is completely different from every other track title], and numerically in order, and you will know instantly at a glance whether the album in SS is in the right order, and further, whether the tracks are in order on any disc you write them out to later. But hey, your choice. If you like titles that don't sort, tracks that have duplicate names, and discs full of things in the wrong order, that's great. Sorry for being snippy, I am having a rather bad night. Apologies for directing my internal nastiness at you.

Generally speaking the mini omnis will give better results for concert recording than the Sony M/S stereo mic. That said, the MS907 is perfectly suited for many other applications. I'll note that the SP-BMC-2s that A440 mentioned use the same elements as the SP-TFB-2s I have. The main difference between them is the "case" style.

I ordered the soundpros mic through minidisc-canada, actually.

Perhaps A440 or someone could make some recommendations. I use SP-TFB-2 mics [soundprofessionals kind that actually go in your ears] and have no complaints about them.

The ECM-MS907 is a rather limited-fidelity microphone for the money. You can find much better mics for the same or less online at places like soundprofessionals.com. What are you planning on recording with the unit? And yes, HiMD and MD units are hard to find here. Wal-Mart and TheSource [previously Radioshack] sell units, but rarely stock anything but downloaders [units that have no line or microphone inputs]. Otherwise no one stocks them, though they can order them in if one wishes to pay 30-50% more than they would if buying online.

Does initialising the disc with SonicStage, or formatting it on the recorder, not make the disc usable?

As mentioned in another thread, this could be because of the read-offset of your optical drive. Also, when transcoding audio, the length of a given track may change slightly, depending on the framelength of each format. Still, there's no reason why track marks should actually *move* perceptibly unless the read offset of your drive is quite large [most drives I've checked this on are within 150 samples of "accurate", though I have seen one drive whose offset was -733, which is over 1/75th of a second - which is still relatively short]. In the end, if what you want is accurate gapless rips to listen to on your HiMD, the only way to be assured that you'll get such is to either rip directly from the original CD or to convert from files that follow CD's 75fps [such as accurately ripped WAV files from Exact Audio Copy or CD-extractor]. Basically, the destination can only be as good [i.e. as accurate] as the source.

Another entry in the free category is Kristal Audio Engine [also in the download section here if I'm not mistaken]. Its interface is somewhat friendlier than Audacity, I've found, though when comparing functionality between the two I find that they're pretty close to par with each other.

Personal opinion [and I've stated it before, I know]: MD and HiMD don't have what it takes to compete directly with hdd or flash players. The properties of both media limit their use when direct comparisons are made; the speed issue alone is enough to put many if not most people off either format. As much as SonicStage has evolved significantly, it's still inadequate for handling playback and download needs when compared to iTunes. Sony have been doing their best [i honestly do think that] to make improvements to SS, but given its lack of support for different formats [something which iTunes admittedly shares, at least on the PC - the Mac version has codecs/plugins for formats [via Quicktime] which the PC version does not], the oddnesses and inconsistencies of its interface [especially confusing "features" such as supporting encoding formats not usable by all Sony's players, and its still-relatively-poor handling of MP3s].. I think that's enough said. SS isn't the beast it was 2 years ago, but it still lacks .. chutzpah. DRM segregation doesn't help, either. Given that iTunes' music store is indisputably the most popular way to buy music online, the battle between Apple, Microsoft, Sony, et al over what DRM mechanism to use is only making the situation worse for everyone, not better. HiMD itself is an excellent format for portable recording. It will eventually be surpassed by flash and hdd recorders, but at this point in time nothing competes directly with HiMD for high-quality portable recording in a consumer-friendly price range. I am actually very happy with HiMD's playback features and use my two portables on a near-daily basis for listening. I have no serious qualms about the sound quality of either my NH700 or RH10, and I find the playback interface to be straightforward enough for the kind of listening I do [usually whole albums]. My own usage pattern does not reflect that of the average iPod user's, though. As has been mentioned already by others here, I am one of those who is not interested in carrying my entire music collection around in my pocket. The biggest limitations with using HiMD for listening, however, still revolve around SonicStage - though I will point out that my own [computer-based] music library also does not reflect that of the average user's; I have music in at least 8 different encoding formats in my collection. The majority of player/library software out there, including both SS and iTunes, do not support playback or transcoding of around 30-50% of my library. In the end, I'll stick with the opinion that in terms of capturing the portable player market, HiMD is too little too late. The format's place in the portable recorder market could probably be expanded through better marketing in that direction, though.

I lack the ability to actually edit my posts with this account. There is a good reason for this, but I'd rather not go into it. This actually is in the suggestions I made: to have SS, upon upload, fill the track number and date fields in the SS database automatically.

By "editing" I mean using the editing functions on the recorder, such as splitting, combining, and moving tracks.

Uh. Select the dupes and hit "delete"? If the tracks are exact duplicates by name, you likely won't be able to sort them in a way that makes selection any easier.

If he's recording from the headphone output of the radio, turn up the volume so it shows properly on the recorder's meters. If the line-output of the radio varies with the volume control, do the same thing. You can also try switching the recorder to manual levels and turning them up. I would suggest trying to turn up what's coming into the recorder first, though [i.e. the above two suggestions].

The only mics that can cause a feedback problem are those patched through the house PA.

Update: while in discussion with ozpeter in another thread, checked the current naming convention for uploads in SS 3.4 .. so bits of what I requested above are already there. New naming scheme is thus:<blockquote>In folder Hi-MD 2006-02-08 05_45_20 track are - 001-2006-02-08 05_45_20.oma 002-2006-02-08 05_45_20.oma</blockquote>&c. So the sorting &c. is fixed, and tracks are numbered. I would change it to this, myself:<blockquote>Folder "Hi-MD 2006-02-08 - 01" or perhaps "Hi-MD 2006-02-08 - Gp01" [for group 1 uploaded]<blockquote>The times are only relevant if the unit being uploaded from is an NH1. Since SS can tell what the unit being used is, times should only be used when uploading from an NH1. Everything else should skip that as it's superfluous information that just makes titles/filenames unnecessarily long and tedious to read. [And yes, I know the date/time thing was my suggestion long ago, but after seeing it put into practise I've realised how cumbersome it is; aside from which, the original intent was to reflect time+date stamps, which no units other than the NH1 support.]</blockquote> containing tracks<blockquote>2006-02-08 - 01 - 001.oma 2006-02-08 - 01 - 002.oma</blockquote> where that's DATE - GROUP - TRACK The reason for moving the date to the beginning of the name? If you dump a lot of files into one folder together, they will all still sort correctly this way, by date, group, and track. You could take all of your uploaded recordings, put them in one folder, and they would all still sort correctly. Further, if multiple uploads are made on the same date, SS should pick up what the last GROUP number was and continue from that point, rather than trying to start back at 01 again when you switch discs and start uploading the rest of your set. Example: disc #1 uploads to folders<blockquote>Hi-MD 2006-02-08 - 01 Hi-MD 2006-02-08 - 02 Hi-MD 2006-02-08 - 03</blockquote> disc #2 uploads to folders<blockquote>Hi-MD 2006-02-08 - 04 Hi-MD 2006-02-08 - 05 Hi-MD 2006-02-08 - 06</blockquote> Much of this whole system may seem redundant, but I at least like to keep things organised in a way that files still sort correctly in multiple different storage situations - organised into folders or not, &c. Some may disagree, but naming files in non-arbitrary, easily sortable ways makes things much simpler for the end user. Files are much easier to find if the names are relevant to the information in them, and if the folders containing them are named in a way that's also relevant. Both truly excellent suggestions. I can't believe I forgot the atrac lossless one myself. As for the gap killer, there are many different ways to implement such a thing. Some concrete suggestions as to implementation would be a good idea. I'd say follow the example of players like foobar2000. . . . also Correction. . . SonicStage: * File Handling/Interface: Make it so when a user changes the name of an album, or deletes an album/all tracks within an album, the empty folder it currently leaves behind shall be automatically removed from the SS library file/folder structure

It doesn't here .. but the time does.. In fact, having just checked recent uploads, another of my wishlist items has been half-fulilled: New naming scheme is thus: 001-2006-02-08 05_45_20.oma 002-2006-02-08 05_45_20.oma &c. So the sorting &c. is fixed, though the times are really superfluous to the filenames/track titles unless the unit being uploaded from is an NH1 [with time/date stamping].

SP = 292kbps = 80 mins on an MD80 "Mono" = single-channel SP = 146kbps = 160 mins LP2 = 132kbps = 160 mins LP4 = 66kbps = 320 mins These are the recording modes available for use with realtime recording, via mic, line, or optical in. With netMD via the PC, there are 3 modes: Pseudo-SP = 292kbps = 80 mins [this is actually LP2 encoding padded out to work as SP mode for older players] LP2 = 132kbps .. LP4 = 66kbps .. Basically, the highest quality you can encode to via PC for netMD is LP2.

This is NOT meant to be a discussion thread. Rather, this is intended to be a place where users can report specific, reproducible bugs, as well as make new feature requests. The last major one of these that I started *was* obviously given some attention by Sony; some of the features requested there *are* in versions of SS released since. So please, be serious, this isn't a pie-in-the-sky request thread [not that you can't, just saying I'll slap you silly if you request 5GB discs again or HiMD-based video cameras]. Be realistic, and base requests on what exists already. And yes, I know that this will quickly become outdated as the last one did. That's the whole idea - make suggestions that can actually be implemented, making the wishlist obsolete. SonicStage: [based on what's currently in SS 3.4] <blockquote><b>* Installation:</b> Create an official, Sony-supported offline installer. The demand OBVIOUSLY exists. <b>* Installation:</b> It's obvious that the installer needs to be far, far more rigorous in checking that systems are up to running SS in the first place. For instance: verifying that XP SP2 is installed; verifying that MDAC is current and functional; and even verifying that the system MP3 codec works properly <b>* Downloading:</b> Investigate the "can't download more than one album at a time" bug more thoroughly as it appears to be the most often-reported bug in SS 3.4 thus far [though not all of us experience it] <b>* Downloading/Transcoding:</b> fix MP3 title length bug that causes SS to gag on tracks with titles longer than 256 characters [simple solution: truncate the long part of the tag during inclusion in the SS database and/or during download - but do NOT edit the track's original tag] <b>* Downloading/Transcoding:</b> fix broken resampling [occurs with MP3s only for me] that causes severe aliasing distortion <b>* Downloading/Transcoding:</b> work on support for MPEG-2 layer III audio; i.e. low-sampling rate, low-bitrate MP3s such as audiobooks <b>* Downloading/Transcoding/Encoding:</b> provide "quality" settings for transcoding using "Convert to.." in the library <b>* Downloading/Transcoding/Encoding:</b> get it over with and simply enable *all* the atrac3plus bitrates that can possibly work with HiMD; the ability to encode to bitrates not supported by HiMD is a major source of confusion for many users <b>* Downloading/Transcoding/Encoding:</b> provide some means of "normalising" tracks, even if it means repeated transcodings, i.e. ReplayGain <b>* Playback:</b> EQ. Please. EQ capable of bass-tuning, specifically, i.e. that has enough bands in the bottom end to do basic room resonance correction. iTunes' and foobar2000's EQ are both good enough for basic correction, for comparison's sake. Lack of EQ is the primary reason I won't use SS as a player on my system. <b>* File Handling/Transcoding:</b> Support within SS for any audio format the user's system has directshow filters for [tag support expected to be inconsistent]. Native support for transcoding from common lossless formats that have dshow filters would save a lot of us a lot of time wasted on WAV conversion, importing, retagging, and conversion, as an example. SS already recognises dshow MP3 codecs such as FFDshow, so why not simply add support for other formats? There is no legitimacy to any claim that any given format promotes piracy more than any other; in fact, the one format which is most widely used for piracy [MP3] is one of those already supported by SS! Lack of file format support is my #2 reason for not using SS as a player. <b>* File Handling:</b> Support for reading ID3v2 and/or APE tags from any dshow-supported audio format [this won't work for everything but will cover the basics for WavPack, FLAC, APE, MP3, &c.] * Uploading/File Handling: Complete removal of DRM from all uploaded self-made recordings duringupload, so OMA files can be backed up without either the SS backup tool [which requires backing up the entire library] or running an extraneous conversion pass to remove DRM that shouldn't be there in the first place. <b>* Uploading/File Handling:</b> Change default upload naming scheme from units that do not support timestamping to substitute track numbers for the current system time in track titles; uploading a series of short tracks currently results in multiple tracks with the same title, which when exported result in names that do not sort correctly; example - "2006-02-08 05:45:20" would be simpler as "2006-02-08 - 01" [and the track number field should be filled with "1"]; this method would result in unique names for all tracks <b>* Uploading/File Handling:</b> Correct filenaming scheme [i.e. currently the first track is foo.oma, second track is foo(1).oma] so that files sort correctly by name alone, and don't use parentheses at all; note that if the above suggestion is implemented, this one is completely unnecessary <b>* Uploading/File Handling:</b> Anywhere that single-digits are currently used in numbering uploaded tracks, use zero padding to assist properly sorting greater than 9 tracks; if the group being uploaded has >99 tracks, pad with two zeros <b>* Uploading/File Handling/Database:</b> Apply track numbers [i.e. the DB field] to uploaded tracks according to their order in each group on originating disc [as already mentioned above] <b>* Uploading/File Handling/Database:</b> Change default upload behaviour so that the "Date Imported" which is used in the title is also applied to the SS date fields for both tracks and albums within SS library <b>* Uploading/File Handling/Database:</b> Since uploads are now separated into albums according to the group structure on the originating disc, number the groups rather than relying on time/datestamps which can get overwhelming, especially with the length of "Transferred from HiMD" already at their beginning; example - rather than "Transferred from Hi-MD (2006-02-06 03:43:14)" use something like "Uploaded 2006-02-06 Group 01" or even simply "2006-02-06 Group 01"; generally speaking we KNOW that the tracks were transferred from HiMD, and don't need to be told so in either the album or track titles. <b>* Uploading/File Handling:</b> Replace default uploaded album title "Transferred from HiMD . . ." with something shorter, such as "Uploaded . . ." [as mentioned above] <b>* Uploading:</b> Do more rigorous testing of SS's handling of tracks with write errors; while this has improved, the behaviour of previous versions [including simply deleting tracks with write errors] is a daunting precedent that implies a lack of product testing <b>* Database/Interface:</b> Change date field-setting behaviour so that albums with all tracks set to the same date automatically set the album date as well [currently only the reverse is possible, setting the album date sets all track dates] <b>* File Handling:</b> "Rename music files" option - split this to segregate this function between OMA and non-OMA tracks; it is useful, for example, to have SS rename uploaded OMA tracks automatically based on changes to their title, but not useful to have MP3s which may be used simultaneously in other library software renamed. This could easily be split into two checkboxes: one for OMA, one for everything else. <b>* File Handling/Database:</b> Change MP3 tagging behaviour so that when full dates are entered, the ID3 DATE field contains either YEAR only or "YYYY-MM-DD" rather than the current very odd and completely non-standard SS format which other programs are rarely able to read as other than garbage <b>* File Handling/Database:</b> Change MP3 tag reading so that ID3 DATE fields containing legal YYYY-MM-DD format are stored properly in SS database [using SS's actual year, month, and day fields] without altering the MP3 tag itself <b>* Uploading/File Handling:</b> Change file-creation behaviour upon uploading to put tracks in folders named as albums rather than putting all uploaded tracks into the "HiMD" folder; optionally, make them a subtree of "HiMD" to keep them separate; it appears this has already been implemented with SS 3.4, great! The default naming scheme makes the folder names a mess, though. <b>* File Handling:</b> Change file-creation behaviour upon transcoding to put tracks in folders named as albums rather than putting all transcoded tracks into the "Optimized Files" folder; optionally, make them a subtree of "Optimized Files" to keep them separate <b>* Playlist/Interface:</b> Add a "Total Time" display as well as "Space Used" to simplify the process of making playlists to fit onto discs - at the moment it's total guesswork <b>* Interface:</b> A "tree view" with albums expandable to show contained tracks would be more accessible than the current system of having to "enter" an album and "leave" it <b>* Interface:</b> A browser/column view would be more usable as well, though this might push up against Apple's patents on the iTunes browsing system [such software patents should be outlawed, IMO] <b>* Interface:</b> dedicate screen real-estate to displaying useful things like the actual library, rather than large whitespaces and frame-edges; at 1024*768 a large portion of the screen is completely wasted, especially on the huge space around the "music source / library / transfer" buttons and the island between "My Library" and the transfer window; IMO, most of the SS interface is unnecessarily wasted space. <b>* Interface:</b> A dedicated screen for editing player contents is highly desirable [rather than being forced to share the screen with half a library view]; rephrased: implement a mode where the full screen can be used to display and edit player contents, similar to the "Import a CD" screen <b>* Interface:</b> Implement [buffered?] "batch-mode" editing of track information on players from the Transfer screen [exactly as editing multiple tracks in the library currently works] <b>* Interface:</b> While in the Transfer view, use checkboxes beside albums in the library to select multiple albums for downloading, similar to track selection in Simple Burner; many users don't know that the SHIFT and CONTROL keys are selection modifiers. <b>* Interface:</b> Integrate Simple Burner; make it possible to transfer tracks directly from CD to a player without creating permanent files in the Library - this one change would make SB itself superfluous - it would also make having to update SB to reflect changes in SB/OpenMG codecs superfluous [such as newly-enabled bitrates and the quality setting] <b>* Editing:</b> Compensate for hardware issue with line-in recordings [repeated sections at end/beginning of contiguous tracks marked automatically by unit] by altering the COMBINE function to check for repeated sections at the meeting point of [i.e. beginnings/ends of] tracks to be combined</blockquote> SS Backup Tool: <blockquote>* Make it possible to back up only OMA files. Tracks that do not carry rights information don't need to be backed up for safety purposes when upgrading: if my OMA library is 4GB of self-uploaded recordings in total, and I want to secure them while upgrading, I don't need to back up 30GB of MP3s as well. This could perhaps be implemented as an "advanced mode."</blockquote> Simple Burner: <blockquote>* Update SB interface to include 352kbps and 192kbps atrac3plus bitrates * Change manual name-editing to work like SS; hitting down-arrow while a track title is "open" pushes it to the next line for immediate editing * Change manual name-editing to include option to TAB to the album title, enabling editing of title and album for compilations without reaching for the mouse</blockquote> General: <blockquote>* Implement some form of bug-reporting mechanism * Data recovery tools! Data recovery tools! Data recovery tools! Data recovery tools! Data recovery tools! Data recovery tools! I could keep repeating this forever, but I think you get the point. *<b> Train your technical support staff; by all appearances, many if not most have never even heard of SonicStage. Their apparent total lack of knowledge on a product that nearly all your current portable audio devices rely on is a serious issue and is causing serious displeasure in many of your customers. It's a pretty sorry state of affairs when your own support staff refer your customers to this forum for help because they can't provide any.</b></blockquote> Pie In The Sky: [Yeah, I know what I said back there, but I had to] Note that the following "modify existing.." lines could just as easily apply as "implement in generation 3 or 4." <blockquote>* Modify existing HiMD firmware to allow enabling of manual record levels by holding the record button for 2 seconds as with older MD units * Modify existing HiMD firmware to allow locking of manual record levels [i.e. the unit "remembers" the setting between rec-stop cycles] * Modify existing HiMD firmware to allow recording at all possible supported atrac3plus bitrates * Modify the firmware in the existing HiMD product line to enable SP, LP2, and LP4 uploading from legacy MD; given the current state of DRM with HiMD uploads, there is no longer any excuse to disallow legacy-format uploads. * If necessary, implement SP uploading as direct to PCM only [assuming this does not violate Dolby patents] * Provide an official Sony atrac/3/plus dshow decoder [playback/decoding only] for non-DRM'd tracks that would permit the proliferation of the atrac/3/plus format; DRM'd tracks to be playable only by users with SS installed; include a playback-only atrac SP codec if it does not violate Dolby patents * Implement *real* SP encoding and downloading for netMD and HiMD in netMD mode if at all possible * If the Dolby patent issue really is the problem with SP encoding/decoding on the PC, then make it available as a pay-for add-in to defray licensing costs * Make an atrac/3/plus codec [not just atrac3] available for Sony Media software such as Sound Forge, Vegas, Acid, and CD Architect, capable of reading and creating OMA files directly; leave downloading to SS</blockquote> Sony engineers: You are more than welcome to contact me personally if you find any of these suggestions interesting but find my language to be vague in any way. I would be more than happy to elaborate or even diagram my suggestions if they are going to be taken seriously. "There is no legitimacy to any claim that any given format promotes piracy more than any other; in fact, the one format which is most widely used for piracy [MP3] is one of those already supported by SS!" .. gah. Way to contradict yourself, boyo. I hope I got the point across, at least. Addendum ... SonicStage: * File Handling/Interface: Make it so when a user changes the name of an album, the empty folder it leaves behind is removed from the SS library file/folder structure

ozpeter: Since your original post title is apt and easily searchable, I'd suggest editing the original entry to reflect this change in SS 3.4 so users who come to this thread can read the working method right off the bat. Just a suggestion, mind you.

Can't be deleted? Why does it matter? Just ignore that it's there. If your current install works, leave it alone. Go to the top of this page, and click "downloads." Simple Burner is in the "programs" section on the second page.

So - here we have a small group of users who are reporting the same problem with the same software. What we need to do is figure out what all of your setups have in common. We can't do this unless you provide this information. So far, all that we actually know is that SS is broken for you. Please read the forum rules and post again with the requested info. There might be something all of you have in common. We can't know until you tell us. btw, I still have had none of the issues listed in this thread happen with SS 3.4 on my machine [except the MP3 titles too long thing, which I was aware of since v2.something].

For your purposes there is no difference between the two versions, except that the US version has Connect Store in it and the Asia-Pacific version does not.

I honestly think most of us regulars are on a par in this regard. You pointed out, for instance, the bit about tracks already edited on the unit, which despite my being aware of I didn't equate to this [as I've never experienced that particular problem, myself]. I'd say either of our suggestions is equally likely. Still, the whole "cold reboot" thing is probably the most important thing, IMO. It has saved my discs more than once.