OESF Portables Forum
Everything Else => General Support and Discussion => Zaurus General Forums => Archived Forums => Software => Topic started by: suruaZ on April 25, 2005, 11:33:18 am
-
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
-
32 gives a very poor result..
try 48 or 64, I record my lectures using 64bit and it sounds great
-
32 gives a very poor result..
try 48 or 64, I record my lectures using 64bit and it sounds great
[div align=\"right\"][a href=\"index.php?act=findpost&pid=76803\"][{POST_SNAPBACK}][/a][/div]
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
-
Indeed, if the sample rate of both the recorder and player are the same then the speed should be the same.
-
I think that if encoder encodes 32k samples per second and decoder decodes 32k samples per second the sound speed must be the same?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=76863\"][{POST_SNAPBACK}][/a][/div]
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.
[...] 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 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
Best regards,
Chris.
-
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..
-
sounds great is relative, im not having the problem suruaz is having.
Awwww, come on, I was just pulling your string a bit
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.
[...] 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..[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=76984\")
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 [confused? Here's the blatant plug: I'm referring to [a href=\"https://www.oesf.org/forums/index.php?showtopic=11336]this[/url] and this (https://www.oesf.org/forums/index.php?showtopic=8142) thread]).
For people interested in Speex, a look at this thread (https://www.oesf.org/forums/index.php?showtopic=9374) 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.
-
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