Jump to content

marcnet

VIP's
  • Posts

    267
  • Joined

  • Last visited

  • Days Won

    1

marcnet last won the day on April 3 2014

marcnet had the most liked content!

About marcnet

  • Birthday 12/24/1979

Profile Information

  • Gender
    Male
  • Interests
    0

Recent Profile Visitors

9,037 profile views

marcnet's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. I do. The 1.00 betas have these extra features: * Better unicode / non-english character handling * Better AT3 file decoding / handling * Decoding of HI-MD mp3 data and mp3 files * MP3 LAME presets * Custom output filename definitions based on track title, album name, etc *File list filter * Encoding of WMA files The reason it's beta is because it had a fairly major re-write for all the above new features. Try beta 4 first. If it dosn't work then try 0.54 instead
  2. No problem. Glad I could help My website has been down for ages - I havn't had the time to fix it - if you wish to donate, then just send it to: marcc <at> nildram <dot> co <dot> uk (I'm sure you can replace <at> and <dot> with the appropriate characters )
  3. To set the recording levels, first use the "show capture" button. This will show the sound waveform of the input without actually storing the recorded sound data. You can use this to tweak the levels. Each of the recording waveforms (the left one of the left sound channel, the right one for the right sound channel) will have two blue lines. These represent the peak level for that sample. If these lines turn red and go to the top/bottom of the waveform display it means that the sound has been clipped (distorted / lost detail) , and the input sound level (volume) should be decreased Pick one of the louder sections of audio you will be recording and play it. I would ensure the recording level make the two blue lines go near the top/bottom of the waveform, but not actually at the top/bottom. Examples attached. The first image is where the blue lines should be for the correct recording levels The second image is where the recording levels are too loud, and should be reduced The third image is where the recording levels are too quiet, and should be increased. Hope this helps. Mark.
  4. I believe from the research I did years ago - the NetMD protocol uploads SP tracks as encrypted PCM to the PC. I made a few posts here suggesting this is the case. http://forums.minidisc.org/index.php?showt...64&hl=netmd
  5. Just a quick thing: I..errr.. borrowed some of the decryption code from this great linux project and stuck it into a beta 5 (not yet released) version of HIMDRenderer. Now this HIMDReneder can take a PCM, HI-SP or HI-LP recorded track (i.e: a track that was not transferred *from* a computer), extract it, decrypt it and convert it. The PCM tracks work just as they do in the linux project - (although I need to swap the byte-order, since my output converted requires Windows compatible PCM data). I extract, decrypt and convert the PCM all within my program Once I did this it was a matter of using this on non-PCM tracks (recorded tracks that are HI-SP or HI-LP). All I do is construct an OMA header without any key data (I just use my own generic OMA header construction code). Decrypt and save the atrac data - exactly as the PCM is decrypted above. The decrypted Atrac data with the OMA header will play in Sonicstage. If it plays in Sonicstage then my program can convert it too. And it works. So this means no Sonicstage needed for uploading tracks to the PC. However, you still need to install it as my program depends on the dlls and stuff that is installed with Sonicstage to decode the atrac data I hope to release beta 5 for general testing - on condition: 1) I get permission from the people who made this linux project - I've used their code to decrypt the Atrac / PCM data (I already had mp3 done myself) 2) People still want my program - it has been a long time since the last update (I've been quite busy)
  6. marcnet

    Using Mac Osx

    If you don't want to pay for VMWare (don't worry... this isn't a warez advert or anything) then try this free alternative - compatible with Apple machines running OsX... http://www.virtualbox.org/ It's not that sluggish either (at least it's not on my quad-core PC )
  7. Why not just import the recording. Convert it to .wav, and then import it into Dragon NaturallySpeaking... That is, if Dragon NaturallySpeaking actually allows import of .wav files directly... Having never used it, I wouldn't know.
  8. Will the "MD recorder" feature of HIMDRenderer work for you?
  9. The HMA files contain encypted ATRAC or MP3 audio data. If the audio data originated from the PC (i.e: you ripped the track using SonicStage) then a play back key is also written to the HMA file. This allows HIMDRenderer to re-construct a working OMA file that SonicStage will play and HIMDRenderer can then convert this as normal. With tracks recorded by a HIMD unit, this play back key is not written. I can still extract the tracks audio data from the HMA file, but IT WILL NOT BE PLAYABLE (sorry to shout). This is because I do not know what play back key to write to the re-constructed OMA file, and so SonicStage will not know how to play the file back and conversion will not work in HIMDRenderer. And I have not worked out how to decrypt the data myself. At the moment - only SonicStage can import recorded tracks. It does this by re-encrypting the data from the HIMD using a different set of keys from what the HIMD unit used.
  10. Could you post a bug report using the built in bug reporting feature. I shall get around to investigating the problem. First my website is knackered, and needs fixing ASAP.
  11. Have you tried HIMDRenderer to convert the large Atrac (OMA) file into something other than .wav. It can convert directly to .flac without needing to convert to .wav first.
  12. Unfortunatly, the content of the disc is encrypted. The only thing that can decode it is Sonicstage It sounds like the track information is somehow corrupted and is preventing conversion somehow. Is the OMA file on the computer the correct size (256/kbits a second is 32 kbytes a second. Multiply that by the length of the track and you should get what size the OMA *should* be). Also, is the copy protection turned off for the track? If not then you can tell SonicStage to convert it to an ATRAC3 file of the same bitrate without copy protection, and see if that file can be converted to .wav.
  13. HIMDRenderer can already decode mp3 data contained within OMA files. I didn't know they could contain WMA data as well. MP3's are encrypted using a simple XOR algorithm, much simpler than the ATRAC encryption. Im not sure how / if the WMA data is also encrypted.
  14. If the files are playable in Sonicstage then my HIMDRenderer program may be what you need. It will show your entire sonicstage library in an easy to use list view, allow you to select multiple tracks in one go (batch mode) and then convert to MP3 using conversion settings of your choice.
  15. Could you use the built in bug report system. That will give me more of an idea of where the problem is occuring since it automatically sends me debug logs, your settings, etc. I do actually check the reports sent to me. However, I do not reply to each one but I do still read them
×
×
  • Create New...