FORUMS
Remove All Ads from XDA

[APP][4.1+] YouTube Downloader v6.7.1

1,603 posts
Thanks Meter: 6,502
 
Post Reply Email Thread
23rd June 2019, 09:27 AM |#3751  
xda_dentex's Avatar
OP Senior Member
Thanks Meter: 6,502
 
Donate to Me
More
@DiamondJohn yes, the above might be a bit OT, but is definitively a useful discussion on the subject. In case of any other question regarding bitrates, audio quality and such, I think I will mention you.

So, the one million dollar question: where would you "stop" the available qualities, regarding mp3 conversion in YTD... considering what's available as audio from YouTube? 192, 256 or 320 kbps? (I would not transcode at all... but that's different. Most people want mp3s anyway).

Thanks.
The Following 7 Users Say Thank You to xda_dentex For This Useful Post: [ View ] Gift xda_dentex Ad-Free
 
 
23rd June 2019, 11:30 AM |#3752  
Senior Member
Flag Sydney
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by xda_dentex

So, the one million dollar question: where would you "stop" the available qualities, regarding mp3 conversion in YTD... considering what's available as audio from YouTube? 192, 256 or 320 kbps? (I would not transcode at all... but that's different. Most people want mp3s anyway).

I transcode to MP3 not for quality, but simply because it is so compatible with so much hardware and software. I use the files on multiple devices, with one MP3 player being over 15 years old, but still going strong

As for the bit rate, for me, its a simple cost-quality calculation. Storage is so relatively cheap, so I go for the highest bit rate. However, in reality,:
1. I understand that the source is bad to start with, so a high quality copy of a distorted sample is arguably a waste. However I repeat, storage is cheap.
2. I actually have headphones with a frequency response of (I *think*) 8Hz to 23KHz. Most people use cheaper headphones with an advertised response of 20Hz to 20kHz. Some people raise the point we cannot hear above 20kHz, however, they miss the point that the device reported 20kHz is actually the point at which the response degrades below a specific level. ie 20.0001kHz is not reproduced acceptably, and 19kHZ may only be just acceptable by the standard; ie not 100%. So, going too high in sound quality may be wasted by the physical reproduction channel (ie conversion from data to physical audio, sound waves, which is analogue). You also have degradation at the DAC and amplifier.
3. I am no longer a spring chicken. My ability to hear the higher frequencies is physically degraded. ie most adults cannot hear the higher frequencies retained in quality recordings.

And to clarify the above, unless you go really low in your MP3 bit rates, most audible quality is lost (or added/distorted) in the higher frequency end. However, really low bit rates will have audible artifacts in the lower end as well. eg mono bass

Historically, 128Kbs has been considered the min bit rate that most people find acceptable; it has been super common since the days of music sharing apps ie Napster and ilk. 192Kbs is approaching a quality that on casual listening, a lot of people have said approaches CD quality. Personally, I find anything below 128Kbs hard to listen to, and 192Kbs as acceptable for most speaker playback. However, as I said, if I can, I encode as high as possible, but usually at or below 320Kbs; above that I personally find it difficult to differentiate the audio with an uncompressed source. Note, I am not talking just about YouTube clips here, I also encode other digital audio.

So in summary, I encode as high as available as disk space is cheap, and into MP3 as its so well supported. Its a personal choice which also depends on your intended playback device and storage choice. Also, if you can use the format no transcoding would always be the best route.
The Following 4 Users Say Thank You to DiamondJohn For This Useful Post: [ View ] Gift DiamondJohn Ad-Free
23rd June 2019, 12:23 PM |#3753  
Senior Member
Thanks Meter: 579
 
More
@DiamondJohn what do you think about using VBR instead of CBR mp3's? Quality of VBR is very good with 245 kbps, I'm using VBR for a while now but Im not sure if it's actually better than CBR 320 kbps. I'm interested in your opinion about that.

Cheers
The Following User Says Thank You to AndrzejDwo For This Useful Post: [ View ] Gift AndrzejDwo Ad-Free
23rd June 2019, 02:04 PM |#3754  
Senior Member
Flag Sydney
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by AndrzejDwo

@DiamondJohn what do you think about using VBR instead of CBR mp3's? Quality of VBR is very good with 245 kbps, I'm using VBR for a while now but Im not sure if it's actually better than CBR 320 kbps. I'm interested in your opinion about that.

I do not know the deep dark secrets of MP3 compression algorithms, however, the word "variable" explicitly states that its not constant. However, the question I would ask is if the bit rate quoted is a maximum or an average? I would guess its a max. If its a maximum, then the 320kbs will be of better quality in the most detailed (data wise) areas of the source, while the VBS could scale down and thus save space, when its not needed. Again, this is all projection based solely on the word "variable" and that to create an average would mathematically require two passes to encode, which I never remember seeing. I have not investigated it, as disk space is not a big issue for me (in regards to music files), its all about the quality and simplicity for me. I am sure it wouldn't take too much searching on the internet to find out what it really is.

Now to take what I would call an uneducated guess, I would guess, at its worst (ie the most complex to encode audio), CBS 320kbs would produce better quality than 245kbps VBR. A higher bitrate would logically catch transient peaks/changes better than a lower bitrate, and I would guess that the "245" is the maximum bit rate it could scale up to. But, CBR would take much more space. Remember, a lot of people state 192kbs as acceptable, almost comparable to CD quality, so either should be OK; if the source was decent to begin with.

But check the above with your own internet search.
The Following 3 Users Say Thank You to DiamondJohn For This Useful Post: [ View ] Gift DiamondJohn Ad-Free
23rd June 2019, 02:52 PM |#3755  
xda_dentex's Avatar
OP Senior Member
Thanks Meter: 6,502
 
Donate to Me
More
@DiamondJohn the VBR setting goes straight to FFmpeg, so, according to their docs, it's an average value.
https://trac.ffmpeg.org/wiki/Encode/MP3
The Following 4 Users Say Thank You to xda_dentex For This Useful Post: [ View ] Gift xda_dentex Ad-Free
23rd June 2019, 05:31 PM |#3756  
uudruid74's Avatar
Senior Member
Flag Kerens
Thanks Meter: 1,396
 
Donate to Me
More
Quote:
Originally Posted by DiamondJohn

You loose data quantity because of compression, however,

I know how it works. And forgive quote shortening - this is taking up too much space.

Quote:

Yes iteratively the errors will accumulate! each lossy format

Try it! The loss should be progressively less until they settle on a common denominator that will be much less severe than your empty cups example. This is because they are selective about how the music is represented and not just throwing data away ad-hoc. They'll end up throwing away parts that have already been lost ... no further loss.

Quote:

believe) your statement that "The only frequency that matters is the original sample rate". If you take a 96Khz 16bit original sample and compress it into a 48kbs MP3 its going to sound a lot worse than a 22KHz 16bit sample compressed to a 192Kbs mp3. A LOT worse.

You misunderstand. It seemed that you were implying that a higher *sample* rate would suffer less loss, like an upsampling after the uncompressing. Doesn't make sense. It wouldn't make sense to imply a higher encoding rate though, since if one could control the encoding rate you wouldn't need to transcode in the first place. Or maybe you are trying to control the encoding of the second format? That could easily use a LOT more data trying to minimize loss, and the majority of loss will occur in the first compression since audio compression codecs tend to drop similar information when encoding. The reason is that its all done in the FREQUENCY domain. You won't make much difference if you can't control the original loss. And depending on why you are compressing it in the first place, may not be possible at all.

I was just saying that upsampling nets you nothing.

Quote:

You have confused the raw sample rate (44.1KHz being the standard CD Sample rate) with the compressed data rate of a lossy format ie 96Kbs. They are totally different things! and should never be confused. One is a

Please don't assume I'm stupid, thanks.

Quote:

I never spoke of changing the original source sample rate; we have no access to the raw audio, only a compressed version. I have only talked of increasing the compression data rate (very different to sample rate)

Thanks for the clarification of your intent, see above while I feel that to be chasing windmills.

Quote:

To repeat myself, the sampling frequency of raw audio is very different to the data rate of a compressed

Please don't repeat yourself, or imply I'm stupid multiple times. The post is long enough already!

Quote:

format. Also, the compression algorithms are very much time based; its approximating the amplitude over time, its not doing a Fourier transform analysis and recreation of the frequencies within the audio.

You're just wrong. Look it up. From Wikipedia ....
"The MP3 Data blocks contain the (compressed) audio information in terms of frequencies and amplitudes. "

"During encoding, 576 time-domain samples are taken and are transformed to 576 frequency-domain samples"
Attached Thumbnails
Click image for larger version

Name:	Image4199444815895980730.jpg
Views:	162
Size:	109.3 KB
ID:	4781639  
23rd June 2019, 05:41 PM |#3757  
uudruid74's Avatar
Senior Member
Flag Kerens
Thanks Meter: 1,396
 
Donate to Me
More
Quote:
Originally Posted by AndrzejDwo

@DiamondJohn what do you think about using VBR instead of CBR mp3's? Quality of VBR is very good with 245 kbps, I'm using VBR for a while now but Im not sure if it's actually better than CBR 320 kbps. I'm interested in your opinion about that.

Cheers

VBR shouldn't specify a bitrate at all, but a quality value. That's the difference.

CBR = Get the best quality you can without going over a selected bitrate.
VBR = Get the best bitrate you can without going under a selected level of quality. Usually represented as a single digit value like 0-9, dependant on the encoder
The Following 2 Users Say Thank You to uudruid74 For This Useful Post: [ View ] Gift uudruid74 Ad-Free
24th June 2019, 02:40 AM |#3758  
Senior Member
Flag Sydney
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by xda_dentex

@DiamondJohn the VBR setting goes straight to FFmpeg, so, according to their docs, it's an average value.
https://trac.ffmpeg.org/wiki/Encode/MP3

Quote:
Originally Posted by uudruid74

VBR shouldn't specify a bitrate at all, but a quality value. That's the difference.

CBR = Get the best quality you can without going over a selected bitrate.
VBR = Get the best bitrate you can without going under a selected level of quality. Usually represented as a single digit value like 0-9, dependant on the encoder

As I said, I don't know the deep dark inner details of MP3 encoding, however, an average doesn't make logical sense to my simple understanding of using a single pass; it would need to see the "future". Further, I did find the following regarding VBR using a quick web search
Code:
The quality is set using a threshold specified by the user to inform the encoder of the maximum bitrate allowed.
http://www.mp3-tech.org/programmer/docs/mp3_theory.pdf
So that reads to me that its not an "Average", and that the "Quality" is defined as a maximum bitrate I have a vague memory that when encoding MP3 there is a separate parameter for quality distinct from bitrate, which I would *guess* allows the encoder to control the encoding speed.

Quote:
Originally Posted by uudruid74

You misunderstand. It seemed that you were implying that a higher *sample* rate would suffer less loss, like an upsampling after the uncompressing.
....snip....
Please don't assume I'm stupid, thanks.
....snip....
Please don't repeat yourself, or imply I'm stupid multiple times.

I NEVER said you were stupid (whatever that means). What you consistently did however was probably an oversight in typing, and your vague use/comparison of Khz with Kbs. One being a sample rate and the other being a data rate. You and I may know the difference but others reading this thread will only get confused by the typo. Sorry if that came across as confrontational or patronizing, it wasn't my intent.

And it is well known and generally accepted that encoding, decoding and re-encoding will lose more and more quality, especially between different formats or even with the same format using variable/questionable parameters. I didn't read the full page , however a simple web search will pull up pages like: http://scruss.com/blog/2012/02/21/ge...3-re-encoding/ In a perfect world with the correct parameters that MAY not be the absolute case, but we live faaaaar from a perfect world. The two images on the page tells most of the story, for those that just want a quick glance, without any reading.

==========
A couple of corrections of what I previously said. oops
CBR is actually constant. I assumed and spoke of it as actually acting like VBR. I wrongly thought RLE encoding would of been a significant part of MP3
Mp3 encoding does use FFT as part of the encoding process, but only as part of the process / decision making.
Regarding the cups example, some water is lost because you pour the water too fast and some splashes out.
The Following 2 Users Say Thank You to DiamondJohn For This Useful Post: [ View ] Gift DiamondJohn Ad-Free
25th June 2019, 05:15 AM |#3759  
Junior Member
Thanks Meter: 0
 
More
MUX error
Every time when i download any video it failed and says MUX failed what to do plz help
25th June 2019, 06:52 AM |#3760  
Senior Member
Flag Sydney
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by coolsuraj143

Every time when i download any video it failed and says MUX failed what to do plz help

logcat?
25th June 2019, 06:58 AM |#3761  
Junior Member
Thanks Meter: 0
 
More
Logcat
Quote:
Originally Posted by DiamondJohn

logcat?

Manufacturer: OnePlus/OnePlus

Model: ONEPLUS A6010 (ONEPLUS A6010_41_190528) OnePlus6T

API v28 (9)

CPU: armeabi-v7a
Processor : AArch64 Processor rev 12 (aarch64)
processor : 0
model name : ARMv8 Processor rev 12 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x7
CPU part : 0x803
CPU revision : 12

processor : 1
model name : ARMv8 Processor rev 12 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x7
CPU part : 0x803
CPU revision : 12

processor : 2
model name : ARMv8 Processor rev 12 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x7
CPU part : 0x803
CPU revision : 12

processor : 3
model name : ARMv8 Processor rev 12 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x7
CPU part : 0x803
CPU revision : 12

processor : 4
model name : ARMv8 Processor rev 13 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x6
CPU part : 0x802
CPU revision : 13

processor : 5
model name : ARMv8 Processor rev 13 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x6
CPU part : 0x802
CPU revision : 13

processor : 6
model name : ARMv8 Processor rev 13 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x6
CPU part : 0x802
CPU revision : 13

processor : 7
model name : ARMv8 Processor rev 13 (v8l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0x6
CPU part : 0x802
CPU revision : 13

Hardware : Qualcomm Technologies, Inc SDM845
Post Reply Subscribe to Thread

Tags
adfree, youtube downloader android dentex free

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes