NOTE: USE OF THIS THREAD AND INFO ASSUMES YOU HAVE LEGAL AUTHORITY TO USE / ENCODE ALL SOURCE MATERIALS. I AM A US CITIZEN AND A SOLDIER, AND HENCE FALL UNDER JURISDICTION OF MANY ORGANIZATIONS, TO INCLUDE THE FEDERAL CENSORSHIP CLUB (FCC) AND THE DOUCHEBAGS MOLESTING CONSUMERS ACT. NO QUESTIONS WILL BE FIELDED REGARDING RIPPING, DOWNLOADING, OR PIRATING OF SOURCE MEDIA, REGARDLESS OF THE INQUIRER'S NATIONALITY. - Fathead, P.I.
This thread will be about video encoding, with the end product being the Raphael. My current Device, Radio and ROM are in my sig and updated for reference.
The premise of this guide: Using freely available (NON-WAREZ) CODEC and software, the user will be able to create video with audio playable on a HTC Touch Pro. The video will be of a watchable quality and small in file size.
Some of you may be familiar with my work on SEGA Dreamcast with GypPlay, DC-Divx, DC-VCD standard, and XDP (X-Rips, Inc. Dreampassport, English translation of DP 2 and above)
- Fathead, P.I.
----- START OF THEOREY -----
If you're like me, the first thing you asked yourself after buying your Fuse was "HOLY ****! I can run 4x the storage on this thing that my old Wizard could!" Yes, 16 GB of Micro-SD goodness is freakin' sweet. But how to use it? You can only listen to so much music per week, even with Napster To Go. You can only play so many games. (I'm further reduced due to lack of a usable joy pad for Pocket Nester.) Why not throw some movies on this joker?
----- VIDEO FORMAT -----
The first thing most people want to know is "What resolution and format should I use?" I am a longtime fan of Divx. I have used it to successfully create video content for low end devices, specifically the SEGA Dreamcast. Creating or downsampling content for a mobile phone gives us a considerable edge over bigger-screen counterparts. Before we jump into the configuration of settings and knob-dicking with software, let's figure out just what kind of video we want to produce.
FRAME RATE
Most content you find will come in one of 3 frame rates:
30 FPS (VHS / NTSC Broadcast / DVD / Blu-Ray(?) )
25 FPS (PAL)
23.976 FPS (Actual frame rate used to record cinema and produce much media)
The first thing you need to realize is that many things initially encoded in 30 FPS can be converted back to 23.976 FPS with no loss of fluidity or data. If your source is a webcam, skip the scaling to 23.976 and drop down to frame decimation. If your source is film, you're in luck. The other frames are just dummy frames that waste a little data. Deleting those frames frees up more video data to better express the picture information in the other 23.976 frames. This trick allows you to:
A. Use a lower bitrate (and hence smaller file) for the same picture OR
B. Get a better picture at the current bitrate
To figure out the frame rate, load up your file in V-Dub and go to File - File Information. The Data Rate box in the Video Stream area will tell you current bit rate, while frame size will give you resolution and frame rate. If you have a 23.976 FPS source, continue. If you have a 30 FPS source that you think should be 23.976 FPS (Film, etc) :
1. Load up the file in V-Dub.
2. Go to the Video drop down menu. Select Frame Rate (CTL+R is shortcut)
3. Change the Frame Rate on the source to 23.976 FPS.
If you continue to have audio sync issues with this method, leave the file at 30 FPS and continue.
Now we are going to look at frame decimation. Frame decimation drops every X frame while keeping the audio sync'd. The end result is a file X the frame rate of the source. While this is noticeable on large screens, on the Touch Pro / Diamond Screens (and probably even the HD), it shouldn't be an issue at all. You can play with this option. It is more noticeable on film, but I cannot see a difference at all on animated sources.
I use the decimate by 2 option in VDub. Video -> Frame Rate (CTL+R shortcut) and select Decimate video frame rate by 2. Our output video is now half the frame rate of our source. The end result is we can:
A. Get a better picture with the current video bit rate OR
B. Lower the video bit rate to get the same picture in a smaller size.
I use option B. Another big advantage here is that the device is trying to decode half the frames. A general rule about audio and video playback: The lower the bit rate you ask the device to handle, the less work it has to do to decode and display the video, and less battery power will be used.
RESOLUTION
Most content you will find is around 640 x 480. DVD sources usually come around 720x480. Blu-Ray would be above that, but possibly scaled down. We are going to watch this movie on a 3 inch screen. Guess what that means? If we never found a video about 320x240, or comparable widescreen resolution, It wouldn't matter. At all. Stepping up to 640x480 is just going to quadruple the amount of pixels we are trying to express on a limited budget.
A handy tool I use in V-Dub is the 2:1 reduction filter (high quality). To kick kit on, go to Video -> Filters (CTL+F). Click add, and it should be the first filter you can choose. This cuts your resolution by half. As a rule of thumb, If I've got a source that's around 640x480 (or 16:9 equiv) or higher, I hit it with the 2:1. You'll find oddball sources like 480 x 360, you can give it a shot, but it might not be worth it. Again, lower resolution means less pixels to express both in bit rate and in reproduction (playback).
Pausing here again, tired as hell.
THE SOFTWARE I USE
Video Editing / Audio and Video Compression and Mux - Virtual Dub. Totally free. I usually refer to this as VDub.
Home
Download
Audio Compression CODEC - LAME MP3 - Free and versatile.
Home
Compiled Binaries
Use the ACM Binary here for Windows and Virtual Dub
Video Compression CODEC / PC and SP/PPC Player - Divx - Decoder, player, mobile player, and MOST of the Encoder are FREE. DO NOT POST ABOUT CRACKING THIS.
Home / CODEC and PC Player
MOBILE (PPC and SP) Player
One more for good measure...
Okay, replies and requests, go!
Am I correct in thinking that videos should be encoded in 640 x 480 ?
*RESERVED*
cucusoft
i use Cucusoft Ultimate DVD + Video Converter Suite
mpeg-4
video bitrate 600kbit/s
framerate, depends from 23.976 to 25 (not important)
videosize 480x368
format 4:3
audio aac
128kb/s
samplerate 48000k
2 chanels stereo
it works fine, no framedrops
played with coreplayer 1.25 build 4506
I just use the standard 700mb divx movie in .avi
I use the free divx player V0.91
Smaller would be sweeter.
Taking a break for a bit, added some new material. Internets in the hotel are barely functional.
I'll be focusing on getting files down to smaller levels. The theorey should give you enough information to start dramatically cutting your file sizes. I've been moving my Boondocks DVD over to Divx 6.8 movies. Averaging 40 megs per episode.
I have been using spb mobile dvd for a few years now. It is very easy to use can convert straight from a dvd or a video file and supports vga res.
Will have to check that one out, have been thinking about backing up my DVD's to mobile, will be traveling about 26 - 30 weeks out of the year and need some boredom killers.
Gonna score some sleep and SEGA time, later all.
Added some new info, taking a pre breakfast nap.
i use slysoft clonedvdmobile. output at vga res and filesize around 700mb seems to run fine for me...although its not free, its well worth the money
Brendo said:
i use slysoft clonedvdmobile. output at vga res and filesize around 700mb seems to run fine for me...although its not free, its well worth the money
Click to expand...
Click to collapse
This is a great bit of software. It also utilises all 4 cores on my Q6600. Another fantastic program is DvDFab which can transcode DVD to Divx/Xvid/MP4 etc on the fly, or dump the Video TS to your HD.
Going to have to check all this out. Have many a DVD that needs ripped. Wonder if any of those have a frame decimation feature. I like my 30 - 40 meg per episode cartoons.
Based on some comments in other threads, I've tried a couple of freeware programs to try to encode in the format that works so well with WMP (MP4, H.264, 640x368, 1000 Kbps, AAC @ 96Kbps): DVD Decrypter + SUPER for one and AutoMKV for the other. However, I haven't been fully successful with either, so I'm hoping that someone who uses these tools can clue me in on the appropriate settings and procedures for encoding.
The combination of DVD Decrypter and SUPER creates very nice movies for playback on the Fuze. Unfortunately, DVD Decrypter keeps the VOB structure from the DVD and SUPER follows suit, which means that a movie will be broken into several pieces at arbitrary points: unsatisfactory, to say the least. The SUPER support forum mentions a way to join inputs into a single output, but following what I understood those instructions to say did not, in fact, result in a combined file.
AutoMKV is very convenient, as it is a single program (or at least UI) to both rip and encode. Unfortunately, I haven't found the settings that generate output that is comparable to the SUPER output -- WMP won't play any of the files I've managed to create so far.
Anybody use these successfully and can share how they do it? TIA.
amerisoft, works very well for me so far, except an occasional blank screen
Just wanted to add...
I don't bother encoding video anymore. Sure, a full-blown 50 minute xvid show might be 400meg. However, the touch pro does not have any issue playing such files back.
Makes life much easier!
I'd agree. I've loaded up a couple of 700MB XVIDs and had no problem playing them.
For some reason, my Sprint Touch Pro has issues playing back even reasonable quality video. For instance, 640x480 video at 1200k (MP4) is a little choppy in WMP, and almost -everything- is extremely choppy in TCPMP, no matter how it's encoded, including 350MB 45-minute XVid TV shows.
AndyCR said:
For some reason, my Sprint Touch Pro has issues playing back even reasonable quality video. For instance, 640x480 video at 1200k (MP4) is a little choppy in WMP, and almost -everything- is extremely choppy in TCPMP, no matter how it's encoded, including 350MB 45-minute XVid TV shows.
Click to expand...
Click to collapse
As I understand it, it's a driver issue. (This is what I've gathered across numerous postings here; someone please correct me if I've gotten something wrong.) The Qualcomm chipset in the TP/Fuze has an efficient driver called Qtv, but Qualcomm charges for a license. WMP appears to incorporate the driver, so it's able to handle moderately challenging videos. 1200 Kbps might be a little more than it's capable of displaying smoothly, but people have reported that 1000 Kbps plays well. On my one trial with DVD Decrypter + SUPER, that was the case for me, too -- full resolution and smooth motion for a video ripped from a DVD with the specs I reported in my earlier message in this thread.
TCPMP, on the other hand, does not include the Qtv driver, so in order to get smooth playback you have to reduce the size, resolution, or frame rate.
Coreplayer has a reverse-engineered partial driver for Qtv. As a result, it falls between TCPMP and WP in capabilities. It is claimed that version 3.0 of Coreplayer will have full Qtv support.
Hey has anyone gotten UHQ to work on bluetooth? I just got in the update and it enables when I plug my headphones into the phone but not when connected via BT. Thanks
Sent from my SM-G920V using XDA Free mobile app
whatnow275 said:
Hey has anyone gotten UHQ to work on bluetooth? I just got in the update and it enables when I plug my headphones into the phone but not when connected via BT. Thanks
Sent from my SM-G920V using XDA Free mobile app
Click to expand...
Click to collapse
Not entirely sure if BT can support the bitrate requirement for UHQ. BT isn't really a data heavy protocol.
Sent from my iPhone using Tapatalk
LNJ said:
Not entirely sure if BT can support the bitrate requirement for UHQ. BT isn't really a data heavy protocol.
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
Okay thanks. Yeah I know BT isnt great for HQ but I guess I was under the impression that the tweaks would work on either.
Sent from my SM-G920V using XDA Free mobile app
whatnow275 said:
Okay thanks. Yeah I know BT isnt great for HQ but I guess I was under the impression that the tweaks would work on either.
Sent from my SM-G920V using XDA Free mobile app
Click to expand...
Click to collapse
To use UHQ on bluetooth connectivity, you must have a compatible Bluetooth Headphone. Check out Samsung Level On Wireless Pro.
Samsung Level on Pro with S7 EDGE
I am currently listening to 24\192 tracks on my S7 edge with PowerAMP alpha and a bluetooth attached Level on Pro. I had my doubts when I read the specs but it is extremely likely that it works for this combination of hardware and software . UHQ via Bluetooth does work.
Galaxy S6 (S6 Edge, Edge+) and S7 (S7 Edge) support UHQ-BT codec developed by Samsung (don't mix with Samsung UHQ upscaler used in stock Music application). This codec allows audio transmittion via Bluetooth 4.0 at a pretty high resulution: 24 bit / 96 kHz (2 channels stereo). In order to be able to use this feature you must use Bluetooth audio device, which supports this codec, for example, headphones Samsung Level series. In order to enable UHQ-BT you need to download the application Samsung Level from Google Play Market and make sure that "UHQ" is enabled. 24 / 96 is the TOP possible limit of UHQ-BT codec for a pair S7 (S7E) + Level headphones. Of course it also depends on the audio file (stream) you're trying to play. If the file itself has low audio resolution with high compression then you cannot get high audio quality. The best audio quality will be when listening to audio files in lossless format (such as flac) with resolution 24 bit / 96 kHz. But there's also a question of how such high resolution was created. One thing is it was made from the original studio recording (made in 24, 36 or 48 bit resolution on professional equipment). And the other thing is if the source for lossless 24/96 audio file was a crappy mp3. A special case would be some vinyl-rip made by an enthusiast on some high-end analog - digital pair. You can find them with resolution as high as 24/192. But most of the time you get some background noise and vinyl crackle. So, the point of such high resolution for vinyl rips in the first place is rather doubtful in my opinion... Also, since UHQ-BT top capability is 24/96 audio resolution, there's no point in using 24/192 for our pair (S7 + Level headphones) UHQ-BT will downscale it to its 24/96 anyway... Other high-res BT codecs available: aptX HD, developed by Qualcomm, which supports HD audio with resolution 24/44, which is a little lower than UHQ-BT. Standard aptX supports CD-audio with resolution up to 16/44, which is even lower. Samsung Galaxy S6 (S6E) and S7 (S7E) support aptX, but do not support aptX HD. If you have a BT audio devise, which supports aptX and are unwilling to get Samsung Level series headphones (Level U, Level U Pro, Level U Pro ANC, Level On, etc...) then aptX supported quality with 16/44 resolution is the highest possible that you'll get. And if your headphones do not support aptX then you will get even lower resolution. The bottomline is get Samsung Level series headphones, if you want to get the highest BT wireless audio quality.
Now, as far as Samsung UHQ upscaler, which is built-in in the Samsung stock Music application, this is a feature, which increases audio resolution programmably. This helps to get the audio sound a little "more smooth" compared with original low-res quality. It removes to certain extent the "digitalness" of the sound, "making connection" between sound "dots" smoother. But it cannot make up high frequency sounds between dots, which may be lost due to low resolution and/or high compression. It simply "doesn't know" they existed.
Hey guys. I swear when I say this that I had a S6 for 2 years and the old samsung music app allowed to enable the UHQ mode even when connected to standard Bluetooth headphones and scrappy speakers started aounding great. In fact I was just surprised at how much of a difference it made. But I updated the app and since then have never gotten it to work over Bluetooth. It still works for wired headphones. But honest to good this feature actually worked and made no difference to which speaker it was connected to.
So I am pretty sure there must be a way to get it to work it is definitely a software matter. I am sure some of you smart folks can figure it out.
What if?
skg27 said:
Galaxy S6 (S6 Edge, Edge+) and S7 (S7 Edge) support UHQ-BT codec developed by Samsung (don't mix with Samsung UHQ upscaler used in stock Music application). This codec allows audio transmittion via Bluetooth 4.0 at a pretty high resulution: 24 bit / 96 kHz (2 channels stereo). In order to be able to use this feature you must use Bluetooth audio device, which supports this codec, for example, headphones Samsung Level series. In order to enable UHQ-BT you need to download the application Samsung Level from Google Play Market and make sure that "UHQ" is enabled. 24 / 96 is the TOP possible limit of UHQ-BT codec for a pair S7 (S7E) + Level headphones. Of course it also depends on the audio file (stream) you're trying to play. If the file itself has low audio resolution with high compression then you cannot get high audio quality. The best audio quality will be when listening to audio files in lossless format (such as flac) with resolution 24 bit / 96 kHz. But there's also a question of how such high resolution was created. One thing is it was made from the original studio recording (made in 24, 36 or 48 bit resolution on professional equipment). And the other thing is if the source for lossless 24/96 audio file was a crappy mp3. A special case would be some vinyl-rip made by an enthusiast on some high-end analog - digital pair. You can find them with resolution as high as 24/192. But most of the time you get some background noise and vinyl crackle. So, the point of such high resolution for vinyl rips in the first place is rather doubtful in my opinion... Also, since UHQ-BT top capability is 24/96 audio resolution, there's no point in using 24/192 for our pair (S7 + Level headphones) UHQ-BT will downscale it to its 24/96 anyway... Other high-res BT codecs available: aptX HD, developed by Qualcomm, which supports HD audio with resolution 24/44, which is a little lower than UHQ-BT. Standard aptX supports CD-audio with resolution up to 16/44, which is even lower. Samsung Galaxy S6 (S6E) and S7 (S7E) support aptX, but do not support aptX HD. If you have a BT audio devise, which supports aptX and are unwilling to get Samsung Level series headphones (Level U, Level U Pro, Level U Pro ANC, Level On, etc...) then aptX supported quality with 16/44 resolution is the highest possible that you'll get. And if your headphones do not support aptX then you will get even lower resolution. The bottomline is get Samsung Level series headphones, if you want to get the highest BT wireless audio quality.
Now, as far as Samsung UHQ upscaler, which is built-in in the Samsung stock Music application, this is a feature, which increases audio resolution programmably. This helps to get the audio sound a little "more smooth" compared with original low-res quality. It removes to certain extent the "digitalness" of the sound, "making connection" between sound "dots" smoother. But it cannot make up high frequency sounds between dots, which may be lost due to low resolution and/or high compression. It simply "doesn't know" they existed.
Click to expand...
Click to collapse
What if I have the S7 and Samsung Level wireless headphones along with the Samsung Level App and the uhq upscaler still is not accessible?
Hi,
Samsung's own UHQA BT audio codec, such as APTx HD or LDAC, has a link bandwidth of 24/96 (512 kbps), but when I connected my Level u pro to my S7 (Exynos) and check it from the developer's menu, it connect with scalable audio codec 16/44. (256 kbps). And I can not change it. in this case 24/96 flac music quality is reduced to cd. Can someone who knows explain?
Hello, I'm going to present to you a method to enable hi-res on the DAC of the Xiaomi Redmi Note 9' family.
The procedure will allow to you to use the full potential of the WCD9385 DAC present (at least) in the Snapdragon 720G.
Indeed, this chip can go up to 32 bits @ 192Khz for PCM stream and can decode natively DSD. Moreover, this chip have a THD+N (Total Harmonics Distortion + Noise) at a level of -108dB, but all audio tests of Xiaomi's phones mesures a THD+N about ~ -96dB, which is the noise floor of 16bits, logic cause by default, this chip is configured to only output in 16 bits mode.
I have setup, tested and experimenting myself on my own phone (Redmi Note 9 Pro - Global Version - MIUI 12.0.2.0 QJZMIXM) this method.
Due to some ROM similarity with other smartphone models in Xiaomi, it will probably works with other smartphones than the Note 9's family, but i will probably need some adjustments if your phone use a different DAC or scheme of audio configuration files.
Before anything :
I'm not responsible of any damage, malfunction or brick that you can do by applying the method. In general, if you don't know what are you doing, just don't do it !
Click to expand...
Click to collapse
Pre-requests :
1) Install ADB, Fastboot and Google ADB Drivers (if you are on Windows)
2) You need to unlock bootloader with Mi-Flash-Unlock (THIS WILL WIPE ALL YOUR PERSONAL DATA, MAKE A SAVE BEFORE STARTING ANYTHING !)
3) Install TWRP for Redmi Xiaomi Note 9
4) You need to root your smartphone with Magisk and install the boot image in fastboot mode that it will give to you.
5) Install ABD_ROOT and ENABLE_ENG Magisk's modules (it will give you the possibility to get root access in ADB) and turn them on for the next device reboot in Magisk App
6) Install MakeSysRW in TWRP (without it we can't remount /vendor partition in Read-Write, and can't touch system's files)
7) Strongly recommanded but not necessary : install Sample Rate Checker from Google Play (with this tool, you can check if the DAC has correctly been set in "HI-RES" mode)
Click to expand...
Click to collapse
Get your phone tuned for Hi-RES :
1) One all of those pre-requests are effectives, you need to get a terminal with adb working (smartphone connected to your PC and debug mode activated) and type :
adb shell mount -o remount,rw /vendor
If you get no errors, you just mounted the partition /vendor on your phone in Read-Write mode, this will allow you to get to the next step, otherwise, i strongly recommand to you to check if you have correctly done all the pre-requests i have described.
2) The next step will save the current audio configuration of your phone (in case you want to return to it for some reasons), still in a terminal window, type :
Code:
adb pull /vendor/etc/audio/audio_policy_configuration.xml ./saved_audio_policy_configuration.xml
adb pull /vendor/etc/audio_io_policy.conf ./saved_audio_io_policy.conf
This will download from your smartphone to your computer the current audio configuration files and save them under "saved_audio_policy_configuration.xml" and "saved_audio_io_policy.conf" in your current directory.
3) Now we will upload configurations files that i've tuned myself, in first case for my personal use.
What changes I've made from the OEM configuration ?
PRIMARY_OUTPUT was in 16 bits @ 48kHz => changed to 24bits @ 192 Khz
RAW_OUTPUT was in 16 bits @ 48 Khz => changed to 24 bits @ 192 Khz
DEEP_BUFFER was in 24bits @ 48 Khz => changed to 24bits @ 192 Khz
Wired Headset, Wired Headphones and Line comes from 16 bits @ 48 Khz, have all been tuned to 24 bits @ 192 Khz
Moreover, i have not touched the integrated speakers because they will not profit to go into 24 bits mode or with an higher sampling rate, and you will get more energy saving by let them as they currently are.
Click to expand...
Click to collapse
If you check the configuration, you will see at points that I tuned this : samplingRates="48000, 96000,192000"
EDIT 22-04-2021 - Few hours after the first release :
I have done this to let Android choose by it's own the sampling rate, because i have seen some sort of clipping on LINE output with OGG (vorbis) files (I assume it will be the same with destructive formats, such as MP3, but it's at least with OGG files) at max volume with very loud musics, i thinks if you set strict resampling at 96 or 192Khz, due to fast algorithms in Android Audio, it will generate some sort of distortion and, if your music is loud enough (and you are at the max volume), it will go over 0dB and clip. So I've maintained sampling rate at 48Khz, and it seems to be well, but if you have some clipping, please tell me in your reply, i will investigate further.
The clipping was effectively done by a resampling mismatches with two configurations files :
audio_policy_configuration.xml (the one that I modified originally)
audio_io_policy.conf
Sampling rates mismatches in audio_io_policy.conf because I left them to the OEM configuration, now it's fixed.
Click to expand...
Click to collapse
You can get my configuration file in the files attached to this post, unzip the files in the current directory where ADB running, then send them to your device :
Code:
adb push ./audio_policy_configuration.xml /vendor/etc/audio/audio_policy_configuration.xml
adb push ./audio_io_policy.conf /vendor/etc/audio_io_policy.conf
This command will overwrite your current configuration files, once again, please be sure to have saved OEM configuration file on your PC !
4) Reboot your phone, and enjoy ! Now you can check with Sample Rate Checker the configuration, you will see something like this (it can be slithly different depending on what is plugged to your phone when you're start the app, in my case i have plugged my phone to an amplifier, so LINE_ANALOG has appears):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
As you can see, AudioManager is in 192Khz mode, BUILTIN_EARPIECE correspond to the front top speaker usesed for private communications, and BUILTINT_SPEAKER is the bottom speaker, both of them have remain untouched.
The most interesting is LINE_ANALOG, corresponding to the phone plugged to a LINE output (a high impedance receiver, such as an amplifier), you can see the different Sample Rates supported, up to 192Khz, and Encodings is ENCODING_PCM_FLOAT corresponding to 24 bits (you can compare it with BUILTIN_EARPIECE and BUILTIN_SPEAKER that they are in 16bits mode).
EDIT : i can't attach the file to my post, anyway i sent it to mediafire and there is the download link
Download the Audio Configuration files tuned for HI-RES
If you have any comments, any remarks or want help, do not hesitate to ask.
22/04/2021 - Few hours after the first post :
I have discovered that the mysterious clipping isn't present when i plug/unplug the phone for few seconds, before appearing.
After some research, try and retries, I've found the problem : the file audio_io_policy.conf
In this file is listed all outputs present in the audio_policy_configuration.xml, but i found that all outputs have a fixed 48 kHz sample rate, which don't match with the concatenated ones in the tuned file.
Concretely, internally the sample rates don't matches, and streams (over)sampled above 48 KHz are some sort of clipped.
So I have concatenated samples also in audio_io_policy.conf, and now it works well with all types of musics.
The first post will be edited with modifications that you need to do with the file audio_io_policy.conf
06/13/2021 :
Xiaomi released an update (MIUI V12.0.1.0 - R****M) which introduce Android 11.
My mod is still perfectly working with this update and Android 11 without any modifications !
So, you can still follow this tutorial to enhance your device audio quality
_xenoxis_ said:
... (deleted)
EDIT : i can't attach the file to my post, anyway i sent it to mediafire and there is the download link
Download the Audio Configuration files tuned for HI-RES
If you have any comments, any remarks or want help, do not hesitate to ask.
Click to expand...
Click to collapse
Your audio_policy_configuration.xml has '<globalConfiguration speaker_drc_enabled="true"/>', and this means DRC (Dynamic Range Control) has been enabled on your all audio outputs. This is the reason the THD+N of your device is larger than that of usual hifi devices. Try replace the true with false in your configuration.xml file.
If you like, see maximizing the audio quality of bluetooth.
zyhk said:
Your audio_policy_configuration.xml has '<globalConfiguration speaker_drc_enabled="true"/>', and this means DRC (Dynamic Range Control) has been enabled on your all audio outputs. This is the reason the THD+N of your device is larger than that of usual hifi devices. Try replace the true with false in your configuration.xml file.
If you like, see maximizing the audio quality of bluetooth.
Click to expand...
Click to collapse
Thanks for your reply, i tried on my device but i don't know if I can hear a difference between before and now or if is it a placebo effect.
Android's audio configuration are poorly documented, what does exactly DRC ?
Thanks again for this tips, it will be added in the mod
The sample rate of AudioManager always 192kHZ, not fit the song dynamically.
Even we ignored energy saving(96kHZ, 48kHZ, etc), but how to handle 44.1kHZ case?
SRC still exist in this case right?
RlTd said:
The sample rate of AudioManager always 192kHZ, not fit the song dynamically.
Even we ignored energy saving(96kHZ, 48kHZ, etc), but how to handle 44.1kHZ case?
SRC still exist in this case right?
Click to expand...
Click to collapse
Yes it doesn't fit the song dynamically (at least them which are lossy formatted songs), but this is the android default behaviour, and instead of putting anything in 48kHz (which can be bad for all musics sampled over 48kHz), with my mod it resampling everything at 192Khz, which can avoid frequencies repliement (cf Shannon-Nyquist's theorem) and can be benefit for the DAC's internal logic and post-treatments.
Anyway, some music players on Android define the "passthrough" flag on lossless formats which tell to Android to not upsample.
In 24bits float, upsampling is very precise, and there's be no distortions audible (if there distorsion, it will happen only close to the noise floor, which is inaudible anyway), so you can consider your 44.1Khz to be EXACTLY the same if they are upsampling to 192Khz.
If it was 16bits, I will not tell you the same, in 16bits, the noise floor is at 96Khz, and there's much more conversions errors in Integer than floats, and much more in 16bits than 24 bits, so in this case, it can be destructive.
_xenoxis_ said:
Yes it doesn't fit the song dynamically (at least them which are lossy formatted songs), but this is the android default behaviour, and instead of putting anything in 48kHz (which can be bad for all musics sampled over 48kHz), with my mod it resampling everything at 192Khz, which can avoid frequencies repliement (cf Shannon-Nyquist's theorem) and can be benefit for the DAC's internal logic and post-treatments.
Anyway, some music players on Android define the "passthrough" flag on lossless formats which tell to Android to not upsample.
In 24bits float, upsampling is very precise, and there's be no distortions audible (if there distorsion, it will happen only close to the noise floor, which is inaudible anyway), so you can consider your 44.1Khz to be EXACTLY the same if they are upsampling to 192Khz.
If it was 16bits, I will not tell you the same, in 16bits, the noise floor is at 96Khz, and there's much more conversions errors in Integer than floats, and much more in 16bits than 24 bits, so in this case, it can be destructive.
Click to expand...
Click to collapse
Thanks!
Actually I am using Apple Music beta version which supporting lossless(even hi-res) resource. What can I do to "passthrough" upsample of Android? I saw a module called AINUR NARSIL in Magisk, is that work?
Two most common lossless formats in Apple Music are 16bit_44.1kHZ and 24bit_96kHZ. As you said, 16bit may cause serious problems? BTW, what's the difference between AUDIO_FORMAT_PCM_24_BIT_PACKED and AUDIO_FORMAT_PCM_24_BIT?
If 192kHZ works fine, how about 384？
RlTd said:
Thanks!
Actually I am using Apple Music beta version which supporting hi-res resource. What can I do to "passthrough" upsample of Android? I saw a module called AINUR NARSIL in Magisk, is that work?
Click to expand...
Click to collapse
You can't force to use the passthrough flag, it only depend on the music player implementation, how it use the Android's Audio layer. Apple Music can decode hi-res resources, but it not guaranteed that it use the passthrough flag behind. Anyway with my mod, even it doesn't use the passthrought flag, it will be upscaled to 192Khz which is sufficient for every hi-res listening.
Remember that the passthrough flag only tell to the Android Audio layer to not resampling the audio, which can be bad with music with a low sampling rate (as 44.1Khz or even 48Khz), cause there's no margin for audio processing in the DAC or high frequencies already in the audio source file.
I don't know about if the AINUR NARSIL mod can force the passthrough, the better is to test it yourself i would say
RlTd said:
Two most common lossless formats in Apple Music are 16bit_44.1kHZ and 24bit_96kHZ. As you said, 16bit may cause serious problems? BTW, what's the difference between AUDIO_FORMAT_PCM_24_BIT_PACKED and AUDIO_FORMAT_PCM_24_BIT?
Click to expand...
Click to collapse
Yes 16 bits may cause interpolations errors only if the destination rate isn't a multiple of the original rate and only if Android make the upsampling by maintaining the output level if the destination sampling rate is a multiple of the original one. This is a bit technical, and I don't know what Android decide and do, but in the worst case, yes, 16 bits integer sound makes more interpolation errors cause 16 bits is less precise than 24 bits float and makes more rounding errors.
For your last question, AUDIO_FORMAT_PCM_24BIT doesn't exist.
According to https://android.googlesource.com/platform/hardware/interfaces/+/master/audio/common/4.0/types.hal :
Code:
/* Subformats */
PCM_SUB_16_BIT = 0x1, // PCM signed 16 bits
PCM_SUB_8_BIT = 0x2, // PCM unsigned 8 bits
PCM_SUB_32_BIT = 0x3, // PCM signed .31 fixed point
PCM_SUB_8_24_BIT = 0x4, // PCM signed 8.23 fixed point
PCM_SUB_FLOAT = 0x5, // PCM single-precision float pt
PCM_SUB_24_BIT_PACKED = 0x6, // PCM signed .23 fix pt (3 bytes)
So there's just two different version of representing 24bits data.
You should take a look here, you'll probably learn some tips on how Android handle audio data
_xenoxis_ said:
You can't force to use the passthrough flag, it only depend on the music player implementation, how it use the Android's Audio layer. Apple Music can decode hi-res resources, but it not guaranteed that it use the passthrough flag behind. Anyway with my mod, even it doesn't use the passthrought flag, it will be upscaled to 192Khz which is sufficient for every hi-res listening.
Remember that the passthrough flag only tell to the Android Audio layer to not resampling the audio, which can be bad with music with a low sampling rate (as 44.1Khz or even 48Khz), cause there's no margin for audio processing in the DAC or high frequencies already in the audio source file.
I don't know about if the AINUR NARSIL mod can force the passthrough, the better is to test it yourself i would say
Yes 16 bits may cause interpolations errors only if the destination rate isn't a multiple of the original rate and only if Android make the upsampling by maintaining the output level if the destination sampling rate is a multiple of the original one. This is a bit technical, and I don't know what Android decide and do, but in the worst case, yes, 16 bits integer sound makes more interpolation errors cause 16 bits is less precise than 24 bits float and makes more rounding errors.
For your last question, AUDIO_FORMAT_PCM_24BIT doesn't exist.
According to https://android.googlesource.com/platform/hardware/interfaces/+/master/audio/common/4.0/types.hal :
Code:
/* Subformats */
PCM_SUB_16_BIT = 0x1, // PCM signed 16 bits
PCM_SUB_8_BIT = 0x2, // PCM unsigned 8 bits
PCM_SUB_32_BIT = 0x3, // PCM signed .31 fixed point
PCM_SUB_8_24_BIT = 0x4, // PCM signed 8.23 fixed point
PCM_SUB_FLOAT = 0x5, // PCM single-precision float pt
PCM_SUB_24_BIT_PACKED = 0x6, // PCM signed .23 fix pt (3 bytes)
So there's just two different version of representing 24bits data.
Click to expand...
Click to collapse
Much to learn.
One more question: your Sample Rate Checker showed that "LINE_ANALOG Encodings" is AUDIO_FORMAT_PCM_FLOAT. I got same result with my earphone. Our related setting should be AUDIO_FORMAT_PCM_24_BIT_PACKED. Thus i am confusing about that. Do you know why?
Here is my log and its screenshots. Some FLOAT words also appeared in it. Looks like Qualcomm handle audio by FLOAT format. I don't know if they have similar reason.
RlTd said:
One more question: your Sample Rate Checker showed that "LINE_ANALOG Encodings" is AUDIO_FORMAT_PCM_FLOAT. I got same result with my earphone. Our related setting should be AUDIO_FORMAT_PCM_24_BIT_PACKED. Thus i am confusing about that. Do you know why?
Here is my log and its screenshots. Some FLOAT words also appeared in it. Looks like Qualcomm handle audio by FLOAT format. I don't know if they have similar reason.
Click to expand...
Click to collapse
AUDIO_FORMAT_PCM_24_BIT_PACKED is the sub-format which is the float format in Android (as showed in my last reply), it contain only factional part and no integer part.
AUDIO_FORMAT_PCM_FLOAT is just a short alias which refer to it.
So, AUDIO_FORMAT_PCM_24_BIT_PACKED is strictly equal to AUDIO_FORMAT_PCM_FLOAT.
Apparently on your device, is it already setup to handle hifi audio in the record processing as well as the output, everything is in 24bits (float) @ 384KHz, which is very nice !
Which device is it ?
_xenoxis_ said:
AUDIO_FORMAT_PCM_24_BIT_PACKED is the sub-format which is the float format in Android (as showed in my last reply), it contain only factional part and no integer part.
AUDIO_FORMAT_PCM_FLOAT is just a short alias which refer to it.
So, AUDIO_FORMAT_PCM_24_BIT_PACKED is strictly equal to AUDIO_FORMAT_PCM_FLOAT.
Apparently on your device, is it already setup to handle hifi audio in the record processing as well as the output, everything is in 24bits (float) @ 384KHz, which is very nice !
Which device is it ?
Click to expand...
Click to collapse
Xiaomi mix2s with snapdragon 845.
Its integrated audio codec DSP is WCD9341, which has better dynamic range than WCD9385(snapdragon 888).
WCD9341 | Qualcomm
www.qualcomm.com
I carry it everyday as a "hi-fi" player.
RlTd said:
Xiaomi mix2s with snapdragon 845.
Its integrated audio codec DSP is WCD9341, which has better dynamic range than WCD9385(snapdragon 888).
WCD9341 | Qualcomm
www.qualcomm.com
I carry it everyday as a "hi-fi" player.
Click to expand...
Click to collapse
I can see the THD+N (Total Harmonics Distortions + Noise) is at -109dB for the WCD9341 and at -108 for the WWCD9385, which is exactly the same (you can't hear the difference, i dare anyone to tell me otherwise).
Don't refer to the "Playback Dynamic Range", which don't represent what is it outputted (you have to add the noise and the harmonics distortions).
You're very right to use it as a everyday hifi player ! I'm very surprise that Xiaomi has think to set the DAC in a hi-res mode by default. I'm wondering why they haven't do the same for their new devices .
_xenoxis_ said:
You're very right to use it as a everyday hifi player ! I'm very surprise that Xiaomi has think to set the DAC in a hi-res mode by default. I'm wondering why they haven't do the same for their new devices .
Click to expand...
Click to collapse
Actually I also changed configs as your mod and turn more items else to 24bit/384kHZ to ensure hi-res works. However, i don't know which features are essential for me.
RlTd said:
Actually I also changed configs as your mod and turn more items else to 24bit/384kHZ to ensure hi-res works. However, i don't know which features are essential for me.
View attachment 5361457
View attachment 5361459
View attachment 5361461
View attachment 5361463
Click to expand...
Click to collapse
"hifi_playback" is just an unused output which isn't routed to anything, so don't mind about it.
About your sampling rate change to 384kHz, this will not gonna set it to 384Khz cause you don't change the file "audio_io_policy.conf" where is the i/o configuration (currently, your configuration can cause some volume saturation as it done the first time I tried my mod on my device).
You need to set 384KHz as well in this file.
Moreover, is it useless to set the USB output over to 192Khz, I don't know a device in USB which can handle 384KHz audio on a USB connection.
However, I don't think there's a reel benefit to set the DAC to 384KHz, I mean the maximum sampling rate in PCM hi-res file is 192Khz (still rare actually) and I never seen anything beyond this value. Typically a hi-res file is in [email protected]
So what i'm trying to say, is that a change from [email protected] to [email protected] is beneficial, for many reasons (16-->24 bits, integer mode to float, increasing sampling rate), but passing from 192KHz to 384KHz is, in my opinion, completely useless.
Moreover, a value that high can increase the risk of causing some jitter (which normally can't happen even at 384Khz, but theoretically the risk increase).
And finally, you'll consume more power for nothing.
_xenoxis_ said:
"hifi_playback" is just an unused output which isn't routed to anything, so don't mind about it.
About your sampling rate change to 384kHz, this will not gonna set it to 384Khz cause you don't change the file "audio_io_policy.conf" where is the i/o configuration (currently, your configuration can cause some volume saturation as it done the first time I tried my mod on my device).
You need to set 384KHz as well in this file.
Moreover, is it useless to set the USB output over to 192Khz, I don't know a device in USB which can handle 384KHz audio on a USB connection.
However, I don't think there's a reel benefit to set the DAC to 384KHz, I mean the maximum sampling rate in PCM hi-res file is 192Khz (still rare actually) and I never seen anything beyond this value. Typically a hi-res file is in [email protected]
So what i'm trying to say, is that a change from [email protected] to [email protected] is beneficial, for many reasons (16-->24 bits, integer mode to float, increasing sampling rate), but passing from 192KHz to 384KHz is, in my opinion, completely useless.
Moreover, a value that high can increase the risk of causing some jitter (which normally can't happen even at 384Khz, but theoretically the risk increase).
And finally, you'll consume more power for nothing.
Click to expand...
Click to collapse
My system is MIUI11. A file called "audio_output_policy.conf" in same place which has the same content as a part of your audio_io_policy.conf. I've edited it and other file called "audio_policy.xml" in case.
Jitter looks getting higher in log but I don't know if I can hear it apparently.
Even I removed all energy-cost-optimizing-strategy on my music app to enhance stability of performance with 384kHZ. The battery cost is still acceptable.
Indeed, it makes me feel little bit weird when adopting 384kHz. All I do this is considering SRC from 44.1kHZ. Higher sampling may cause more reasonable curve in analog signal. However, it depends on algorithm and may cause other problems like harmonic wave and jitter. So it's an experiment and a trade-off. I will go back to 192kHZ if got nothing on 44.1kHZ files after comparing.
_xenoxis_ said:
"hifi_playback" is just an unused output which isn't routed to anything, so don't mind about it.
About your sampling rate change to 384kHz, this will not gonna set it to 384Khz cause you don't change the file "audio_io_policy.conf" where is the i/o configuration (currently, your configuration can cause some volume saturation as it done the first time I tried my mod on my device).
You need to set 384KHz as well in this file.
Moreover, is it useless to set the USB output over to 192Khz, I don't know a device in USB which can handle 384KHz audio on a USB connection.
Click to expand...
Click to collapse
I'm making a USB Sample Rate Changer script like bluetooth LDAC and usb-samplerate-unlocker (up to 386kHz and even 768kHz). If you like, see my github USB Sample Rate Changer and usb-samplerate-unlocker.
Update 08/07/2021 :
Hello guys, i have made a magisk module with this mod, it's currently on submission stage and it will be, normally, fully available in the magisk module repository (the "market").
With this magisk module, the mod will be systemless and will no require tricks to hard-modifying files on the device !
I'll keep you informed about this !
Great work.
I need to do the same in my K20 pro (Raphaelin), for the apple music lossless to use the inbuilt hifi dac