Jump to content

dex Otaku

Limited Access
  • Posts

    2,462
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by dex Otaku

  1. dex Otaku

    hiatus

    Going on hiatus again. If the board is lucky, I will never return.
  2. Sounds like you're encoding to HiSP [256kbps], which gives a usable 7:55 recording time. Using HiMD's own audio format [atrac3plus] you can also encode to: LPCM [uncompressed, 94 minutes] 352kbps [just under 6 hours] 192kbps [just under 11 hours] 64kbps [aka HiLP 64] [around 33 hours] 48kbps [aka HiLP 48] [around 42 hours] What you deem to be the minimum acceptable quality is up to your ears. Check SS's encoding options, try encoding to each bitrate, and see what you prefer. Choose your own compromise between time vs. quality.
  3. http://forums.minidisc.org/index.php?showtopic=14222
  4. Just out of curiosity, have you not switched the menu language to your own [or at least, one of those available that you understand better than Japanese]?
  5. Man I wish I could gets them that cheap here [where they're almost 4x that price].
  6. When you import your MP3s into SS's library, it reads the existing tags. If you keep well-tagged MP3s [unlike most people] then the results it imports, and subsequently tags the same tracks with when they're downloaded to a player, are quite readable. The difference is basically made by whether you keep your tags orderly or not. SS does have limitations relating to the length of individual tag fields [like truncating stupidly long song titles]. There as also a limit to how much text you can send to the player [rather, a specific disc] in tags as well, but I believe that for the 1GB discs this limit is in the tens of thousands, which most users would be hard-pressed to fill just by downloading albums of pop music.
  7. There is very limited support for on-unit playlisting [by using bookmarks]. On the other hand, you can divide the tracks you're downloading into groups [i.e. "for driving", "for chilling out" &c.] using SS. SS has playlist tools [you could make a playlist for driving and download it into a single group called "for driving"], and while they serve a basic purpose SS lacks a few features [like being able to randomise the playlist before downloading] of other library software. SS also lets you import M3U playlists from other software [but has been known to create duplicate entries in its library if the tracks were already there, in the past at least - haven't tried this with 4.0 yet]. I myself rather like using MD80s [reformatted for HiMD] which with 192kbps a3+ audio gives you about 3hrs/disc. This is just around the right amount for me to make single artist compilations and such while still maintaining navigability on the disc without ever having to look at the remote's or unit's display to see what's coming up.
  8. You can already do that, and have been able to for quite some time [since WDM drivers came out with Win98 if I'm not mistaken]. The choice is somewhere between the hands of the programmers and the users - between what the programmers want to stick you with [i.e. progs like SS that have no playback options at all] and what the user wants to use [i.e. foobar2000 and the like with ASIO, DirectSound, "WAVEOUT", kernel streaming, &c.]. I'll note that the DirectSound method [which allows individual control per program] has the added cost [sound-quality wise] of using a mixer that is either software or hardware [depending on your sound adapter and drivers] with multiple layers of processing which adulterate the sound. Some of us find that annoying [because we want the stream getting to the DAC to be exactly what was decoded by the player without any processing or with only the processing we choose].
  9. SS's volume control uses the main control for everything ["Master Volume"] This affects everything coming out of your sound card.. Some programs use a control that is only for the stream they are playing [and won't affect anything else] through DirectSound. Others use the control for the WAVE output [which will affect anything playing back digital audio but nothing else]. Open your system mixer, play with the volume control in various programs, and you should be able to tell [immediately] which one they're using by which slider [if any] follows.
  10. Excellent response, tekdroid. My $0.02 is the a version: The RH1 is a recordist's unit and its interface as well as the additional features others are unlikely to use are optimised for recording use. Anyone who doesn't understand this after even a cursory glance at the unit with the display on deserves to get burned for not buying a player-oriented unit such as the RH10. "My $0.02 is the a version" should read, "My $0.02 is a short version"
  11. What exact format and bitrate [of aa3] were you using?
  12. ren *.aa3 *.oma There ya go. Also, side-issue: the atrac codecs for Sony's pro suite of tools won't open files with DRM on them [or at least, the version I have won't]. This means that any kind of transcoding [of, say, tracks you recorded yourself on your HiMD] must also be stripped of DRM before SF can even open them. I've been using SF since about 1992 or 93. It has its place, to be certain.
  13. Try http://users.pandora.be/satcp/eac-qs-en.htm As for the slight echo - what encoder were you using? I've been using EAC for years and have never had such a problem [not that I don't believe you are, of course].
  14. Doesn't EAC do this properly? I mean, I've used it for such with FLAC and MP3. I just don't recall if the tags were 100% right off the bat because I almost always mass-edit them with MP3BookHelper or Foobar2000 after encoding anyway.
  15. I missed that part. * Thou shalt not reply to forum posts after drinking a whole bottle of grenache-shiraz.
  16. If I'm not mistaken, a foot pedal was made for the [still being produced] "court reporter's" model of standard MD, which was made specifically for transcription purposes. Unfortunately I don't know the model # off the top of my head, but I do believe that of the 2 models I recall being like this, both were silver, fairly large even for MD, and had a built-in speaker. One also had a 2nd MD recorder in it specifically for duplicating/2nd-copying [for legal purposes] recordings as they were being made [this model I believe is NOT made any more]. In any case, Avrin is correct in that a foot pedal could be fashioned using a cable from any Sony MD remote - caveat being that recording would have to be started on the unit, the remote being for pause/unpause and stop only during recording.
  17. #1 - Why on earth are you using high sens mode to record anything louder than, say, a lecturer all the way across a hall, or birdsong? #2 - The way the gain on the mic input works appears to be like this: input -> preamp w/gain setting [low or high, ~15 and 35dB I believe] -> manual level control [this is NOT variable gain for the preamp, it's a level control AFTER the gain is applied, hence the preamp clipping regardless of what levels are set at - though in your case, turn off high sens mode, that should at least help a bit]
  18. Check out "Microphone University" at http://www.dpamicrophones.com/ . There are suggestions there on stereo techniques. I'd say picking a specific technique and sticking to it, and subsequently mastering the recording on a decent pair of monitors [they be speakers] - EQing, &c. - would go a long way. Expecting to get a perfect "sounds great on every system" recording without any editing, EQ, &c. is almost unreasonable. Still, I think the best advice of all is to master for the medium - listen to your recording on speakers when mastering, and take it elsewhere to check it out on others' systems to see if they show any glaringly obvious faults that your own setup doesn't, and incorporate what you learn into your mastering process.
  19. What used to be the case was that WAV files of artibtrary length [i.e. not an exact length of frames] would have trackmarks moved to the nearest whole frame boundary [probably back rather than forwrad, too]. WAV files of exact lengths in frames [75fps, 588 stereo samples/frame] would end up gapless with track boundaries where they should be. It appears that this may have changed [for the worse] around SS 3.4 to nearly random behaviour, though it does seem to make a difference what exact source the tracks are coming from [CD, CD image, WAV files, &c.].
  20. Yes, you're using your RH1 as an external DAC. There ar simpler ways [that are less stressful on the equipment] to do this though. Your turtle beach sound adapter likely already has a good output on it for headphones. If it lacks the power to drive 'phones, you'd likely be better off just using an external headphone amp. The write laser + magnetic head [since both are used for writing] should be in standby mode [the unit buffers data to be written, so it doesn't have to been written as it's converted in any case], but you're still causing wear to the equipment by leaving it in pause.
  21. Yes, MP3 on nearly all hardware players has gaps. ATRAC and its variants are among the only gapless lossy formats for portables on the entire consumer market. That's assuming you're dealing with a 1st-generation encoding [i.e. ripped directly from CD]. As to whether the MP3 bug is worse than the added artefacting of transcoding - that's up to the user's ears. The only way to find out is to try it. It also depends on what you're trying to encode, as different kinds of music [sound, rather] are more difficult to encode than others. I personally find that MP3s encoded at bitrates >192kbps survive the transcoding process very well. 192kbps MP3 -> 192kbps a3+ is about as low as I'll go, and while the 2nd-generation artefacting is audible at that rate, it's not as unpleasant or annoying as MP3 that's been repeatedly re-encoded [from MP3]. Whether I transcode my MP3s or not depends on how well they were encoded in the first place; low-rate or trashy encodings stay as MP3 [i'd rather deal with the EQ than the added loss], and high-rate, well-encoded tracks I tend to transcode. Again, the only way to find out is to try it and see what you're comfortable with listening to.
  22. Despite what I've said about uploading post-editing [on the unit] working fine, I'd upload the entire thing -before- editing on the unit just in case. I'd still recommend as the least stressful and time-consuming methods either combining everything with SS [and adding trackmarks/splits in your editor after] or simply adding everything to the timeline of your editor and subtracting the bits you don't need. I'd get carpal tunnel trying to deal with that many trackmarks on the unit itself. For CD-burning, I tend to take my projects to a friend who has CD Architect. There are certain things it doesn't do [such as CD-Text] but otherwise it's a straight redbook CD layout editor that you can actually do all your basic editing right on the timeline of if you prefer. [i find CD Architect to be one of the most brilliantly-designed single-use interfaces of any program I've ever used, to be honest. Even the very old versions are far more functional for the single purpose of making audio CDs than any other software I've ever tried for that purpose. Its one serious missing function is the ability to write directly to an ISO image or WAV with cuesheet, though it does support creating an encapsulated WAV+cuesheet that is usable only by it.] For pretty much everything else I use Nero. I find Nero too slow for [gapless] audio CD layout [because it doesn't pre-render images and its editing facilities are in fact simply slow] but it is functional.
  23. --- Tag handling: After importing MP3s, since the "album view" of the library has no date fields in it at all, if a user sets the dates in this view [so that things will sort chronologically, which is part of how I catalogue all non-orchestral/classical/baroque/whateveryouwanttocallit music] then the DATE tag on some [but not all] of the tracks [i have been testing this with MP3s since SS2.1] will be overwritten with SS's proprietary, used by no other program I've yet seen date format [specifically, YYYY,MMDD or YYYY/MMDD depending on what you look at the tag with afterwards]. The files it selects to overwrite the tag in appears to be a completely random operation, as it doesn't do it with everything. From that point on, any attempt to manipulate [such as mass-rename] files including the date tag will be corrupted by the presence of this completely out-to-lunch date format they're using. Viewing tags from any other software that doesn't truncate the date field at 4 digits will also produce bizarre and unreadable results. SONY: If you MUST edit the date tag in tracks that are not native to SS [MP3, WMA, and now AAC] then PLEASE either restrict the date written to the 4-digit standard followed by basically everyone else on earth, or use the ISO 8601:2000 date format [YYYY-MM-DD] which has the advantages of working when truncated to 4-digits as year alone, being easily human and machine-readable, and always sorting correctly using the simplest sort algorithms available. Your date format has none of these advantages [except perhaps machine-readability, though that is questionable since every other program I've tried to use files whose tags have been mutilated by SS has reacted in different ways to your assinine date format]. Better yet: why not have a checkbox under "advanced" in the SS prefs, as there is now for "rename files whose info is edited in the library" which allows users to TURN OFF SS's mutilation [i.e. completely unnecessary rewriting] of tags on all formats other than OMA? -- The CDDB lookup feature is next to useless. It will eventually find your tage for you, and its guessing does work, but it takes so long [5-15 minutes for a single 12-track album that is already partially tagged [album name and artist] using a 3Mbps downstream DSL connection and with nothing else running] that I can't imagine anyone actually sitting through it searching for tags for an entire library of files [and then having to approve them one-by-one] .. it would take hours or even days just to do this. I've seen other software attempt this and do so admirably, so it's Sony's implementation of it that appears to be at fault here.
  24. Notes I've made so far: Database usage is generally faster. This is good. Indigo is good. The interface still wastes way too much screen real-estate. Still no EQ. Consider: Winamp had an EQ under Windows95 on 32MB Pentiums. Other players have had EQs for years. In fact, OpenMG Jukebox and SS 1.5 had EQ. So really - what is the excuse not to have an EQ? Some of us use computer speakers, and without a bit of correction for said speakers or for room resonances, things are quite literally unlistenable. There are still issues with process priority. Certain operations [such an conversion/encoding] are total CPU hogs which bog the system down; others [simple playback] get interrupted by other processes far too easily [and make SS appear to be hung, when in fact it's just waiting for that other process with *normal* priority to finish]. AAC / M4A importing lacks any support whatsoever for tags. This is bad. [Tested with FAAC converted tracks from Fb2k and iTunes created tracks] Re-importing OMA tracks after re-initialising the database [i.e. deleting everything from the database but not deleting the files, then re-importing the files] requires re-setting the "Various Artists/Compilation" tag for any albums that require such. This suggests that while tags are included in the OMA files, this one particular flag is either not written to them at all or is completely ignored upon import. Importing MP3s with the "various" tag positively flagged also does not work. This suggests that perhaps importing -anything- with this tag on it will not work properly. Should test with WMA and AAC as well to verify. Importing MP3s - SS now appears to sort correctly by track number the first time around. Importing anything - SS still does not set the DATE field for the main library view, regardless of whether all tracks in an album are set to the same date. After re-initialising my library, I no longer have a single album with a date tag from this view. Date tags are correct when viewing by album and transfer correctly when downloading to players as they did before. Is it so hard to implement a bit of code that tells SS when constructing the database "If all the tracks in a particular album have the same date, set the main date field in the database to match"? This is an incredible pain in the ass to those of us who sort our [non-classical] music libraries chronologically. Still no way to "randomise" playlists. Still no indication of playlist size or duration when editing [duration available in library views of playlists] Dynamic playlist displays both duration and size [not sure if it did before as I rarely use this function]. This is good. "Date Imported" - perhaps in the case of OMA tracks at least, this should be written to and retrieved from the file's own tags? This way, the original date of upload [for HiMD recordings], import, or conversion from another format would be retained [which is way more useful than simply the date the files were added to the current db]. As it stands now, if a user re-initialises their database, all tracks will have the same date with slight variances in the time as their "Date Imported," which is, quite frankly, useless as shit. Limitations imposed by the library view are, well, too limiting. Classical listeners in particular find this a pain, as it's more common to search first by composer, not conductor or orchestra. While various tagging formats have fields for artist, composer, &c. - and SS does recognise them - they aren't used by the library. This may affect a minority of users, but it shouldn't be impossible to address the fact that many users find the artist/album/date sorting method to be too constricting. Point being: the default view should be more customisable. And no, the "Sort by" option does not even begin to address this [it actually makes things worse, not better]. Being able to easily select sort criteria and their order should be a primary goal for any library system meant to hold large amounts of data [such as several thousand songs]. The lack of file format support is still annoying. While we as users may or may not realise that support included by Sony requires licensing, there are other ways of doing thing. In particular, publishing the details for a "file format API" or something would be a viable option. This would enable users to take open source format plugins and write the necessary chunk of code to allow, say, a FLAC or WavPack dll to be used from SS and for tag support to work. Or maybe I'm naive in what I know about licensing OSS codecs to be used with commercial software. I just don't understand why it seems like Sony find so necessary to make their software hard to use and inaccessible or incompatible with what their users [read: target audience] actually want and use. Interesting note from SS' help: Note that the copy protection is added to the following tracks anyway: <UL><LI>Tracks downloaded from a music service site </li><LI><b>Tracks recorded on an MD device</b> or a recording device compatible with certain types of Memory Stick </LI></UL> Now - after having relaxed the restrictions on uploaded tracks in basically every other sense, why are they bothering to still do this? All they're doing is making life harder for their users, who often don't recognise the need to either strip uploaded tracks of DRM, export to DRM-less formats, or use the SS backup tool - and subsequently lose their own recordings because they have DRM on them that make them useless in the event of a disc or OS crash, reinstallation, &c. At this point, this is simply ludicrous.
×
×
  • Create New...