Hi, I've search many place and unable to find any good guides for video conversion for the Acer liquid(Donut). And the User Manual don't even give full specs.
I've done many conversion of my own, however the video always lag...
~~ Please tell what is the max bitrate, best codec(mp4, h.263, etc), resolution, fps to make a video play hi quality NO frame skip/lag on the Acer Liquid(Donut)~~
Note: I understand the max quality is only as same as the video/clip you've inputed, and that the Acer only support up to 20 frame per section(at least that's what written in the user manual), and I have a good video converter btw, been using it for years...
Shalala
Alrite after playing with the video for a few more day.
I STILL don't get exactly what I wanted...and I notice alots of people viewing this thread, so I'll share what I have at the moment.
~~~Good Enough~~~
Right this moment, my best conversion is...
Video Quality Superb
File Format *.MP4
Video Codec mpeg4
Resolution original as input/ since no TV-out, it is suggest 640x480 up to 720x480.
Framrate Always try to maintain the same or near framerate as the original video clips. To see how many fram per second the original clip is...right click on the video clip and choose properties > Details > Frame Rate.
Aspect Ratio either Auto or 16:9.
Audio Quality 128 kbps
Audio Codec mpeg4aac
Channels 2 Channels Stereo
Sample Rate Varies/44100 Hz
NOTE: I can't be sure if its just my phone in particular, I've only gotten it for a week. I don't wanna think that it is my phone that don't play video perfectly. However, the setting above allow me to play full screen with no frame skips, hi quality, almost everything is perfect with 1 exception.
The frame don't skip but it seem to lagg a "LITTLE BIT"... an example, you won't see black strips or shifting from 1 scene to another, but rather.....crap i can't explain it lolz
n00b here. Recording a video with the audio at only 8000 Hz sounds like your camera is in a toilet. Are there any 3rd party camera apps that can do 16000 Hz, or maybe a hack for the default app?
I can successfully change bitrate and resolution for video encoding in build.prop, but changing any values for the audio just causes the camera app to force close. Failing at that, I looked up the AMRNB codec and found that it doesn't support 16000 Hz at all anyway. My next misguided idea was to change the default codec stuff from this
Code:
ro.media.enc.hprof.codec.aud=amrnb
...
ro.media.enc.hprof.aud.bps=12200
ro.media.enc.hprof.aud.hz=8000
ro.media.enc.hprof.aud.ch=1
to AAC, like it is in the Droid/Milestone
Code:
ro.media.enc.hprof.codec.aud=aac
...
ro.media.enc.hprof.aud.bps=96000
ro.media.enc.hprof.aud.hz=16000
ro.media.enc.hprof.aud.ch=1
I realize they are different phones, but I figured it was worth a shot. Failed again, naturally.
Can anyone shed some light on this? Why did HTC give us DVD resolution video with only telephone quality audio? That's like having an HDTV with only a piezo buzzer for a sound system. I do not understand this decision at all.
+1
I have noticed this as well, but I assumed it was a hardware restriction.
If there can be any light shed on this let us know!
Really good idea. I was thinking of adjusting the frame rate so that it always remained at a constant 24 fps, rather than going down to 9 fps in indoor conditions. Any suggestions?
gsmsosv said:
n00b here. Recording a video with the audio at only 8000 Hz sounds like your camera is in a toilet. Are there any 3rd party camera apps that can do 16000 Hz, or maybe a hack for the default app?
I can successfully change bitrate and resolution for video encoding in build.prop, but changing any values for the audio just causes the camera app to force close. Failing at that, I looked up the AMRNB codec and found that it doesn't support 16000 Hz at all anyway. My next misguided idea was to change the default codec stuff from this
Code:
ro.media.enc.hprof.codec.aud=amrnb
...
ro.media.enc.hprof.aud.bps=12200
ro.media.enc.hprof.aud.hz=8000
ro.media.enc.hprof.aud.ch=1
to AAC, like it is in the Droid/Milestone
Code:
ro.media.enc.hprof.codec.aud=aac
...
ro.media.enc.hprof.aud.bps=96000
ro.media.enc.hprof.aud.hz=16000
ro.media.enc.hprof.aud.ch=1
I realize they are different phones, but I figured it was worth a shot. Failed again, naturally.
Can anyone shed some light on this? Why did HTC give us DVD resolution video with only telephone quality audio? That's like having an HDTV with only a piezo buzzer for a sound system. I do not understand this decision at all.
Click to expand...
Click to collapse
YES!
I agree 100%. Maybe the idea was to create a suitable MMS birate/container solution w/ no regard to ANYONE else... there has to be a way. in fact I'm excited that you were able to at least play w/ the video and adjust bitrate & res. Care to share how to a layman?
AMR sounds like garbage. In addition to the incredibly low samling frequency, the bitrate is ~ 12.5Kbps. I would say that's a cut below telephone SQ.
Can any people in here far smarter than me, tell us if one can hackney a difference audio codec (say mp3?) as AMR seems too limited to work with. Or maybe a 3rd party app... why are there NONE?
this seems to make it seem possible:
http://developer.android.com/reference/android/media/CamcorderProfile.html
I would really love this on my Desire. Currently both video and audio are crap, audio especially. Here's a little demonstration I made, where I went to see which encoding type is better, mpeg4 or H.264:
http://www.youtube.com/watch?v=CgW28VE0eOo
justin.tv app mitigates this for now, as the video uploaded to justin.tv in near realtime is markedly better than the abysmal quality of the native android app, which just goes to show how dysfunctional it really is.
for now, I'll use justin.tv whenever recording videos... it goes to show that many android phones (inc. my hero) are capable of so much more in the hardware, and the limiting factor is crappy software devs and/or requirements.
M-JPEG/MJPEG provides the possibility for relatively low-resource software decoding. If the Nook Color is up to the task at 800 MHz or even 1.1 GHz of decoding 24 fps and/or 30 fps M-JPEG streams at 1024x600 with relatively good compression quantizers, this could be one way of getting super-sharp, native-resolution playback working.
Does anyone know if any of the presently available media-players which run well on the Nook under any of the available OS flavors supports M-JPEG or could be modified to do so?
Obviously, this potential means of getting true 1024x600, even if it works, won't be for everyone. The files and raw bitrates will be massive compared to the 848x480 AVC files that many seem to be encoding so as to make use of the hardware decode ability. Depending on the speed of the flash-RAM being read from, there may also potentially be a bottleneck/buffer under-run issue there as well. But for those who are willing to go through the trouble of encoding to such a seldom-used codec and, if necessary, purchasing a microSD card with a confirmed high read-speed*, the benefits may outweigh the drawbacks.
Any discussion, ideas, information, and especially testing of these ideas would be much appreciated.
*be aware that SD Class ratings apply to sustained write and don't necessarily have a direct impact upon sustained read speed.
Full discloseure: I don't yet own a Nook Color, but am incredibly excited about purchasing one.
Sample clip to try out
Here's a sample clip to try, if anyone would be so kind. This is not the greatest or sharpest source material ever, it's intended more as proof of concept, but it should give an idea of the feasibility of this. The first half of the video is letterboxed, but the second half is full-screen 16:9 @ 1024x600, 29.97 fps.
Thanks in advance!
Skyrim Trailer: http://www.slingfile.com/file/2T6bd1yuXF
Encoded to M-JPEG .avi using XviD4PSP 6.0.3 Portable.
MediaInfo:Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 2mn 53s
Bit rate : 19.1 Mbps
Width : 1 024 pixels
Height : 600 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.035
Stream size : 394 MiB (99%)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 2mn 53s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 2.65 MiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.72 video frame)
Writing library : LAME3.98.2
We just need some extremely skilled assembly programmer to come along and write a NEON optimized software decoder. The CPU is pretty powerful if that aspect is leveraged. Unfortunately that is a non trivial task lol
I've read that the DSP is actually more powerful than meets the eye but the docs necessary aren't available. That could be incorrect though... But considering its a somewhat flexible DSP it is a shame that they don't release the details becausewho knows what it could be used for if our wacky community went at it.
Yeah, it seems to me, though I'm a complete noob regarding this device/platform and don't even own one yet, that the people behind the scenes enabling all this stuff are pretty talented and enthusiastic, and will continue to uncover much hidden potential in the device.
As for native 1024x600 video via M-JPEG, though, even just as a proof-of-concept, I'd really love to hear from someone who's willing to give playback of it a shot, as I think it has potential (not necessarily my test file though) to blow the up-scaled 854x480 AVC video most people are encoding out of the water. Do you have an NC you could try it on?
I gave the video a try. It plays very smooth but there is an occasional stutter. It's very close. Looks excellent in quality.
I used QQplayer and am at 1100mhz.
Excellent! Thank you very much for trying it. Does your system generally play hardware-decoded videos with no issues at all?
If you're interested, keep an eye on this thread, eventually I'll post something with super-sharp pic quality and the audio lowered to 44.1 KHz and a bit lower bitrate, so we'll see if that helps at all.
Thanks again for taking the time to download, try it, and report back.
swaaye said:
We just need some extremely skilled assembly programmer to come along and write a NEON optimized software decoder. The CPU is pretty powerful if that aspect is leveraged. Unfortunately that is a non trivial task lol
I've read that the DSP is actually more powerful than meets the eye but the docs necessary aren't available. That could be incorrect though... But considering its a somewhat flexible DSP it is a shame that they don't release the details becausewho knows what it could be used for if our wacky community went at it.
Click to expand...
Click to collapse
I'm sure Android coders of VisualOn have already put their VOME Engine (http://visualon.com/english/Android/vome.htm, see also some descriptions and even a demo in older posts of my blog fineoils.blogspot.com) into their NookColors. At some point in this January, they even promised to donate their (compiled) code to AOSP 2.3 repos. However, nobody has seen it though, and the VisualOn is completely mum of that slip of their tongue.
In other words, yes, our ARM's CPU is powerful enough to make so-called "software" decoding which hardly ever missing a beat compared to a dedicated hardware decoder. Then I argue that what is missing in our NEON/2D/3D framework is hardware (shaders of SGX) overlay. Yet YouTube apk knows how to utilize it, Flash 10.0...10.1...10.2, lots of players don't.
Then, the new TI OMAP SGX code is presented for kernels 2.6.36+, we don't have such a luxury yet in our CM7. CM Team are perfectionists, they supposedly aiming for a clean stable build of 2.6.32 capable to be used on all and every 30+ smartphones too many of which aren't even based on TI OMAP chips.
As for assembly, it might be useful to squeeze some 3...5...10 additional fps when optimizing memory/cache I/O operations and/or something else operating on the low level. We might discover that with the new kernel everything of 720p/2Mbit/sec will start playing as per specs automagically, or some clever tweaks of video/audio buffers, cache could bring serious improvements to video playback even with the "old" 2.6.29 kernel.
Very sharp test file ready to download & test
Here's a test file that, if it plays well, might show the potential for really sharp video playback. It's 1024x600 @ 23.976, down-scaled from a Blu-ray rip that was full-screen (or maybe 1.85:1) 1920x1080. I adjusted the audio to be 96 Kbps, 44.1 KHz MP3 (I can't seem to get AAC to work in an .AVI container). It's the first minute of the Just Say Yes music video from Get Him To The Greek, prior to any NSFW language or anatomy.
Encoded with XviD4PSP v.6.0.3 beta full-install, M-JPEG quantizer of 1.
Audio encoded with Lame via VLC.
download:
http://www.slingfile.com/file/NfqRe61AWl
MediaInfo:
Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 59s 935ms
Bit rate : 17.4 Mbps
Width : 1 024 pixels
Height : 600 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.184
Stream size : 125 MiB (99%)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 59s 716ms
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 700 KiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 26 ms (0.63 video frame)
Interleave, preload duration : 26 ms
Writing library : LAME3.98.4
a.fenderson said:
Here's a test file that, if it plays well, might show the potential for really sharp video playback. It's 1024x600 @ 23.976, down-scaled from a Blu-ray rip that was full-screen (or maybe 1.85:1) 1920x1080. I adjusted the audio to be 96 Kbps, 44.1 KHz MP3 (I can't seem to get AAC to work in an .AVI container). It's the first minute of the Just Say Yes music video from Get Him To The Greek, prior to any NSFW language or anatomy.
Encoded with XviD4PSP v.6.0.3 beta full-install, M-JPEG quantizer of 1.
Audio encoded with Lame via VLC.
Click to expand...
Click to collapse
Tested. No issues, playback is perfect.
CM7 Stable, OC kernel @ 1.1GHz, Moboplayer 1.1.139 (V7-Neon which is ARMv7 optimized)
a.fenderson said:
Here's a test file that, if it plays well, might show the potential for really sharp video playback. It's 1024x600 @ 23.976, down-scaled from a Blu-ray rip that was full-screen (or maybe 1.85:1) 1920x1080. I adjusted the audio to be 96 Kbps, 44.1 KHz MP3 (I can't seem to get AAC to work in an .AVI container). It's the first minute of the Just Say Yes music video from Get Him To The Greek, prior to any NSFW language or anatomy.
Encoded with XviD4PSP v.6.0.3 beta full-install, M-JPEG quantizer of 1.
Audio encoded with Lame via VLC.
download:
http://www.slingfile.com/file/NfqRe61AWl
MediaInfo:
Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 59s 935ms
Bit rate : 17.4 Mbps
Width : 1 024 pixels
Height : 600 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.184
Stream size : 125 MiB (99%)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 59s 716ms
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 700 KiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 26 ms (0.63 video frame)
Interleave, preload duration : 26 ms
Writing library : LAME3.98.4
Click to expand...
Click to collapse
wow this clip looks so amazing. how big of a file would the whole movie be? also would u be intrested in doing a small youtube video on how to acheve this?
Wow.. Mobo player playes that perfectly, where vital player (my previous favorite) chokes hard.....
And holy hell.. it even plays a 1280x720 recording i made from my Incredible, that no other player would play. Man, forget motion JPEG, its all about this player!!
thanks for testing, all!
daedelus82 said:
Tested. No issues, playback is perfect.
CM7 Stable, OC kernel @ 1.1GHz, Moboplayer 1.1.139 (V7-Neon which is ARMv7 optimized)
Click to expand...
Click to collapse
Awesome, thanks for testing!
cowballz69 said:
wow this clip looks so amazing. how big of a file would the whole movie be? also would u be intrested in doing a small youtube video on how to acheve this?
Click to expand...
Click to collapse
Therein lies the issue. This is relatively ineffecient codec, space-wise, because it's intra-only: MediaInfo reports the video bitrate as 17.4 Mbps, which is comparable to Blu-ray bitrates of 1920x1080 material. This clip is exactly one minute @ 125 MB, so at 90 minutes this would be (depending on how you define 1 GB) between 10 and 11.25 GB. For a 2-hour, 120-minute film, you're looking at around 15 GB. There may be further refinements to the bitrate possible, through lowering the quanitzer a bit during encode, but you'll likely lose quality quickly and end up being better off with up-scaled, hardware-decoded AVC @ 854x480.
As for the YouTube how-to, I'm not very good on camera, and I'm quite sure that the method I used was very inefficient--I just had to use the apps I'm familiar with, apart from XviD4PSP, so for now I'll give a brief workflow, to be followed by a detailed written step-by-step, and then I'll let someone smarter than me boil that down to an easier process.
This assumes a non-branching disc with one single .M2TS file comprising the entire feature:
1. Decrypt & rip BD to HDD via AnyDVD-HD--for content you own, IF this is legal in your location, some restrictions apply.
2. Demux the video and audio streams of the feature .M2TS file into their raw components using tsMuxeRGui 1.10.6.
3. Use VLC's Convert/Save function to convert the audio to raw MP3, down-sampled to 44.1 KHz at 96 Kbps, stereo/2-channel.
4. Remux the original demuxed video and the new MP3 audio track to .TS via tsMuxeR
5. Drop the file into XviD4PSP (link warning: although this program is great, the site is one huge monolithic Silverlight monstrosity--it is composed of slow and fail), and convert to container .AVI, video M-JPEG scaled to 1024x600, compression quantizer 1; leave audio intact via "copy".
6. Enjoy near-HD goodness.
Divine_Madcat said:
Wow.. Mobo player playes that perfectly, where vital player (my previous favorite) chokes hard.....
And holy hell.. it even plays a 1280x720 recording i made from my Incredible, that no other player would play. Man, forget motion JPEG, its all about this player!!
Click to expand...
Click to collapse
Now THAT is good news! But please give details on the clip: codec, bitrate, encode-options if known, and is it actually high-detail that ends up looking comparable or better than the "Just Say Yes" M-JPEG clip, with no stuttering or other issues? Would it be possible to share a segment of it so others can try to reproduce the playback?
I may have spoken too fast, as the audio comes across as a loud hiss... but the video is flawless. If you want to try it:
http://dl.dropbox.com/u/19844443/VIDEO0021.3gp
The video plays with hardware decoding mode on BTW.. its just the audio that isn't playing right.. bummer..
a.fenderson said:
Here's a test file that...
download:
http://www.slingfile.com/file/NfqRe61AWl
Click to expand...
Click to collapse
OMG I tested your video clip and WOW. It looked freaking amazing. It is by far the best quality I have seen yet on my nook. I think proof of concept is confirmed.
Audio works fine for me as well
I wonder if a profile for Xvid could be made that would have low enough CPU usage on playback. There are a number of settings that reduce playback complexity.
For example,
http://forum.doom9.org/showthread.php?p=398214
I'm not a big fan of encoding videos to a specific device because said device will be obsolete within a year anyway. We are really close to having handheld devices that will play anything.
I think most of our software players are using a port of FFMPEG and I'm not sure how optimized that is for ARM NEON. A Google search does show some talk about NEON optimizations though. But I'm thinking that it could go a lot farther given some time...
http://www.google.com/search?hl=en&...official&q=ffmpeg+neon&aq=f&aqi=g10&aql=f&oq=
Be thankful for the popularity of ARM cpus. It helps make things happen.
just to let u guys know the audio and video was PERFECT , no audio stuttering and im sure its due to the newest test kernel and alsa patch. so if u have audio issues with his clip he uploaded def flash new test kernel and alsa
Divine_Madcat said:
I may have spoken too fast, as the audio comes across as a loud hiss... but the video is flawless. If you want to try it:
http://dl.dropbox.com/u/19844443/VIDEO0021.3gp
The video plays with hardware decoding mode on BTW.. its just the audio that isn't playing right.. bummer..
Click to expand...
Click to collapse
Thanks. I've remuxed your 720p MP4-ASP file to an AVI, with the original video intact, and the audio converted to mp3 @ 64 Kbps (you're not losing much quality here, subjectively), and the sampling rate was already super low. Try it now, if you want, maybe this will play: http://www.slingfile.com/file/wC8Wczp3d6
Excerpts from MediaInfo on your original file's video (it must have lost lots of this header info in the remux):
Format : MPEG-4 Visual
Format profile : [email protected]
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : 20
Duration : 18s 234ms
Bit rate mode : Constant
Bit rate : 8 000 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.527 fps
Minimum frame rate : 5.000 fps
Maximum frame rate : 33.333 fps
Color space : YUV
Bit depth : 8 bits
Scan type : Progressive
Excerpts from MediaInfo on the reencoded audio:
Audio
Codec ID/Hint : MP3
Bit rate mode : Constant
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 8 000 Hz
colbur87 said:
OMG I tested your video clip and WOW. It looked freaking amazing. It is by far the best quality I have seen yet on my nook. I think proof of concept is confirmed.
Audio works fine for me as well
Click to expand...
Click to collapse
Great, thanks! I actually hated having to lower the quality of the audio as per recommendations in this thread (props to dalingrin et al), because at this bitrate I can hear compression artifacts really easily, but if I could find a way to stick M-JPEG and AAC in a workable container, maybe the increased quality will help negate the low bitrate. Or, maybe the lower sampling rate has more impact than the lower bitrate and we could bump the audio Kbps back up--more experimentation needed, but I don't have access to the rip until I get home.
swaaye said:
I wonder if a profile for Xvid could be made that would have low enough CPU usage on playback. There are a number of settings that reduce playback complexity.
Click to expand...
Click to collapse
See above--Divine_Madcat was playing 720p MP4-ASP/XviD-encoded material, with only slight audio problems. See if the remux I posted works on yours with audio intact.
For example,
http://forum.doom9.org/showthread.php?p=398214
I'm not a big fan of encoding videos to a specific device because said device will be obsolete within a year anyway. We are really close to having handheld devices that will play anything.
Click to expand...
Click to collapse
On the one hand, I completely agree--this is a lot of work to produce some really huge files that don't necessarily have much use elsewhere (apart from iPads, from which specs I actually got the initial idea), but on the other hand, even if it's only for having one super high-quality sample clip that plays absolutely perfectly so I can show it off to my geek friends and family and leave them stunned at the quality, it'll be worth it.
I think most of our software players are using a port of FFMPEG and I'm not sure how optimized that is for ARM NEON. A Google search does show some talk about NEON optimizations though. But I'm thinking that it could go a lot farther given some time...
http://www.google.com/search?hl=en&...official&q=ffmpeg+neon&aq=f&aqi=g10&aql=f&oq=
Be thankful for the popularity of ARM cpus. It helps make things happen.
Click to expand...
Click to collapse
Bring on the optimizations!
a.fenderson said:
Great, thanks! I actually hated having to lower the quality of the audio as per recommendations in this thread (props to dalingrin et al), because at this bitrate I can hear compression artifacts really easily, but if I could find a way to stick M-JPEG and AAC in a workable container, maybe the increased quality will help negate the low bitrate. Or, maybe the lower sampling rate has more impact than the lower bitrate and we could bump the audio Kbps back up--more experimentation needed, but I don't have access to the rip until I get home.
Click to expand...
Click to collapse
I never said anything about lowering the bitrate. If you can tell a difference between 48K and 44.1K on the horrible nook audio then props to you =P
Any audio issues related to sample rate are fixed now anyway
dalingrin said:
I never said anything about lowering the bitrate. If you can tell a difference between 48K and 44.1K on the horrible nook audio then props to you =P
Any audio issues related to sample rate are fixed now anyway
Click to expand...
Click to collapse
Thanks for the info, and I'm sorry--I didn't mean to misquote you. Lowering sampling rate to 44.1K and bitrate was the overall plan I came away with after reading through that entire thread. It's great to know that the audio sampling rates can be high enough to maintain near-transparency. And no, I can't tell a difference between 48K and 44.1K sampling rate, all other things being equal, even on half-way decent equipment. No golden ears here.
Edit: when I said "maybe the lower sampling rate has more impact than the lower bitrate" I meant on playability, not on audio quality. My bad.
a.fenderson said:
Thanks for the info, and I'm sorry--I didn't mean to misquote you. Lowering sampling rate to 44.1K and bitrate was the overall plan I came away with after reading through that entire thread. It's great to know that the audio sampling rates can be high enough to maintain near-transparency. And no, I can't tell a difference between 48K and 44.1K sampling rate, all other things being equal, even on half-way decent equipment. No golden ears here.
Edit: when I said "maybe the lower sampling rate has more impact than the lower bitrate" I meant on playability, not on audio quality. My bad.
Click to expand...
Click to collapse
No worries, i just wanted to make it clear.