Help - Search - Members - Calendar
Full Version: Playing Shine Encoded Mp3 Files
OESF Forums > General Forums > General Support and Discussion > Software
suruaZ
Anyone knows why Shine encoded mp3 files are too speedy while playing it?
I use the same bit rate 32000 for encoding and decoding. As player I tried mpegplayer and madplay.

Thanks,
suruaZ
dreadlocks
32 gives a very poor result..
try 48 or 64, I record my lectures using 64bit and it sounds great
suruaZ
QUOTE(dreadlocks @ Apr 25 2005, 12:01 PM)
32 gives a very poor result..
try 48 or 64, I record my lectures using 64bit and it sounds great
*


Sory I was not clear enough. 32k is a samples rate, bits rate is 128 kbs.
I have no problems with quality but with re play speed.
I think that if encoder encodes 32k samples per second and decoder decodes 32k samples per second the sound speed must be the same?

suruaZ
omega
Indeed, if the sample rate of both the recorder and player are the same then the speed should be the same.
chrget
QUOTE(suruaZ @ Apr 26 2005, 06:40 AM)
I think that if encoder encodes 32k samples per second and decoder decodes 32k samples per second the sound speed must be the same?
*


The operative word here is if. My guess is you may have run into one of the peculiarities (read: bugs) of the kernel / sound driver provided with the Sharp 3.13 (and possibly other?) ROMs. Seems that the SNDCTL_DSP_SPEED when applied to /dev/dsp1 will not become active immediately, but rather when the device is next opened. So in other words, sampling will be performed with the rate of the previous application to access the audio input (or possibly a default after suspend/resume/reboot).

The workaround is to start shine (or any other capturing application), abort it and then restart it. The second time around, the sampling rate will match and things will be alright.

QUOTE(dreadlocks @ Apr 25 2005 @ 12:01 PM)
[...] try 48 or 64, I record my lectures using 64bit and it sounds great


Now that is really an exaggeration if I ever heard one wink.gif I can think of many things to say when it comes to shine, but 'sounds great' is certainly not a phrase that comes to mind rolleyes.gif

Best regards,
Chris.
dreadlocks
sounds great is relative, im not having the problem suruaz is having.
well in my lectures the professor wears a microphone and I sit under one of the celing mounted speakers using the built in mic on my 5600, comparing the quality of the sharp voice recorder to the shine encoded mp3 I can tell no obvious diffrences, besides the fact I can record several hours of lectures using shine.. now If I was trying to sample a direct input or mebe with a better mic I might expect shine would sound far from "great", but for my very specific uses it performs admirably..
chrget
QUOTE(dreadlocks @ Apr 26 2005, 10:10 PM)
sounds great is relative, im not having the problem suruaz is having.

Awwww, come on, I was just pulling your string a bit wink.gif

Shine is a nice little piece of software, no doubt about it. And, as I mentioned earlier, suruaZ's problem is not really related to shine but rather to the ROM/kernel in question, or so it seems.
QUOTE(dreadlocks @ Apr 26 2005, 10:10 PM)
[...] using the built in mic on my 5600, comparing the quality of the sharp voice recorder to the shine encoded mp3 I can tell no obvious diffrences, besides the fact I can record several hours of lectures using shine.. now If I was trying to sample a direct input or mebe with a better mic I might expect shine would sound far from "great", but for my very specific uses it performs admirably..
*

I'm quite sure it does. As I said, I think shine is a Good Thing.

I 'solved' the Sharp Voice Recorder's main shortcoming (i.e. the high data rate through the use of plain PCM .wav files for recording) using a combination of a few lines of C-Code that captures from the audio device to stdout, a shell script and speexenc, thus producing nice low bitrate .spx voice recordings.

Obviously with Speex being a voice codec, general audio quality will not quite be the same as shine's, but for voice it's certainly more than acceptable, and at a much lower bitrate at that (it can go as low as 5-6 kBps while still producing amenable results). In the simplest case, speexdec will play back the resulting files, but other players usually will do as well (for me, lamip and vlc obviously come to mind biggrin.gif [confused? Here's the blatant plug: I'm referring to this and this thread]).

For people interested in Speex, a look at this thread might be of interest.

Eventually I will most likely move on to AMR though, once I manage to make the encoder run in realtime on the Z, mainly for reasons of convergence (modern-day mobile phones can play back AMR files and/or even send them using MMS [Multimedia Message Service]), even though I prefer the fact that Speex is an open, royalty- and patent-free codec.

Best regards,
Chris.
suruaZ
QUOTE(dreadlocks @ Apr 26 2005, 12:10 PM)
Seems that the SNDCTL_DSP_SPEED when applied to / dev/dsp1 will not become active immediately, but rather when the device is next opened. So in other words, sampling will be performed with the rate of the previous application to access the audio input (or possibly a default after suspend/ resume/reboot).

The workaround is to start shine (or any other capturing application), abort it and then restart it. The second time around, the sampling rate will match and things will be alright.


Yes,exactly! From the second try and up everything is OK. Thanks chrget!

suruaZ
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.