The VideoLAN Forums

The information bubbles in the Preferences thing are very helpful, but they have two major flaws :

-Firstly, they stay on one line. And some are so long you can't read the end of them even with a 1280x1024 screen. That's pretty dumb, no disrespect. I think a line break should be introduced before the 80th character of each line.

-Secondly, they disappear after like 5 seconds, at least on Windows. That's irritating, you're there, trying to read what it says, and after 5 seconds it goes away. So you have to roll-over another option to get another bubbles and then go back to the one you tried to read, and do this every 5 seconds.

Oh also, why is the sound volume setting linear? It's pretty inconvenient because it means that the incrementation in volume is inconsistent, if you're in a higher setting incrementing by a fixed amount will change little, as if you're on a low volume setting basically every time you move it a notch things get twice louder. May I suggest taking the iTunes volume control as a reference? They got that one right. By the way if you have some trouble with the logarithmic algorithm required for that I can help.

Also, can't we cache local streams or something? Because basically I get a lot of hiccups from videos when they can't read from the hard drive in time, so I'd like VLC to say, always have the next 5-10 seconds of the file I'm playing in RAM so that I don't get those (mainly sound) hiccups (which often enough prevent the comprehension of what's being said, which is fairly irritating). Basically that would be great for systems under heavy load, including hard disk load. I like to have a couple of virtual machines running, a couple of instances of Firefox open and Azureus and eMule operating concurrently while I'm watching a video

And finally, wouldn't there something to be done about sound/video sync? Oftentimes I get the sound and video desynced and I have to go back a few seconds every once in a while to get them synced again. That's annoying too.

Thanks for listening to my whining

PS : Oh also, could we get custom aspect ratios? Defined by two integers like XXX : YYY? Because basically, sometimes, I have 16:9 videos that are stretched to 4:3, but my screen itself is ina 4:3 resolution stretched to 5:4, so in this case I'd need an aspect ratio of 64:45

Information bubbles, not our issue, but Qt or wx. Have you tried the latest NB about those issues ?

Logarithmic volume is a NO GO for me.

RAM caching exists for linux version.

Audio/Video sync is already there since a long time.
Custom AR too.

Information bubbles, not our issue, but Qt or wx. Have you tried the latest NB about those issues ?

Logarithmic volume is a NO GO for me.

RAM caching exists for linux version.

Audio/Video sync is already there since a long time.
Custom AR too.

No I don't use nightly builds, I stick to stable releases.

Why would anyone be against logarithmic volume? That one truly boggles my mind, I'm honestly curious about it, what's so desirable about linear volume?

Why does RAM caching only exist on the Linux version?

If audio/video sync is already there, why do I have to do what I do? (disclaimer, I only upgraded from 0.8.6c a few days ago)

By the way, tu habites à Cone? Ca explique le logo?

Logarithmic volume is very difficult to get a precise value. Moreover, this needs a complete change inside VLC core, so I still think it is a no-go. If you want that, code it.

If you don't use and try the NB, then, we cannot discuss with you about the regressions...

Why RAM caching does only work on linux ? Because noone coded it outside of linux ?

Logarithmic volume is very difficult to get a precise value. Moreover, this needs a complete change inside VLC core, so I still think it is a no-go. If you want that, code it.

If you don't use and try the NB, then, we cannot discuss with you about the regressions...

Why RAM caching does only work on linux ? Because noone coded it outside of linux ?

lol, logarithmic volume isn't that difficult (disclaimer, I recently adapted my spectrograph to support native logarithmic frequency scale with user-defined bases, so I guess I kind of wrapped my mind around that sort of problems), and you don't have to change anything about the VLC core. It's only a user interface issue, that is the user interface deals with 'esoteric' logarithmic volume values that a magic little function converts into your good old linear values to the core.

Since value 512 is 100% (am I correct?) our function would make it be 0 dB (decibels are good for that), the max which is 1024 would be roughly +6 dB and the min which is 1 would be about -54 dB. For the sake of simplicity we'll use floats for the logarithmic values, although we are free to use fixed point values, but why bother. Here's how the conversion would work (I didn't miss the "If you want that, code it." part ) :
..and you would use these functions to convert between the core (which would still be all about linear values) and the user interface.

May I suggest that then you make the volume scale from -54 to +6 with increments of N dB (as defined by the user, my recommended default would be 3 dB). You would only have to change how it's set in the preferences (from -54 to +6 instead of 0 to 1024), how it's written to the config file and actually you would hardly have anything to change to the interface I think.

And I really don't see why RAM caching would have to be platform specific really.. you'd think that it would be all about loading chunks of the binary file into an array.. unless.... it wouldn't be based on /tmp now, would it??

Well, sorry, for users, having a volume that doesn't grow linearly is weird for all video players. (look at any DVD player...)

About RAM, if you think it is easy, just code it. (If you don't understand why this is Unix only, then google 'mmap').

Well, sorry, for users, having a volume that doesn't grow linearly is weird for all video players. (look at any DVD player...)

About RAM, if you think it is easy, just code it. (If you don't understand why this is Unix only, then google 'mmap').

I totally think we should have a poll for that one . Or better yet, go the fancy schmancy way and make it an option! hehe . After all it would only take one box to tick (for the user) + the decibel incrementation step thing to define (would take a slider?). But somehow I seem to sense that you're quite opposed to that idea. Too bad..

ha of course, mmap, didn't think of that one. If I may, why is mmap required for that? Is there anything done in mmap()ed memory that couldn't be done in a plain old malloced chunk of memory? Note that I didn't claim or even imply it was easy

I am not against any combobox or option. I will welcome the patch, review it and apply it. But I will not code it.

Hi,
haven't you changed your mind about an option of logarithmic volume slider implementation after some time? Almost every software working with the sound follows the well known psychoacoustics phenomenon - sensitivity of the ear is much closer to logarithmic curve than to linear one. There are some examples in the discussion with recommendation how to solve it in relative simple way. It's a shame if so useful option is missing for so long time in such a wonderful piece of software.
Rgds,
Hugo

Hi,
haven't you changed your mind about an option of logarithmic volume slider implementation after some time? Almost every software working with the sound follows the well known psychoacoustics phenomenon - sensitivity of the ear is much closer to logarithmic curve than to linear one. There are some examples in the discussion with recommendation how to solve it in relative simple way. It's a shame if so useful option is missing for so long time in such a wonderful piece of software.
Rgds,
Hugo

Yup, I agree (obviously, considered my previous posts), however I feel to compelled to point out that more than a psychoacoustics phenomenon, it's simple explained by the fact when it's logarithmic, everytime you change the volume a notch, the ratio by which you change the volume is fixed, so you don't even need to resort to psychoacoustics to explain that it makes sense to use a logarithmic scale rather that a linear scale which would make volume vary wildly in the lower notches and very little in the upper half.

I for one implemented a logarithmic volume knob in my commercial program that goes from -30 dB to +30 dB and it works just great!

Yup, I agree (obviously, considered my previous posts), however I feel to compelled to point out that more than a psychoacoustics phenomenon, it's simple explained by the fact when it's logarithmic, everytime you change the volume a notch, the ratio by which you change the volume is fixed, so you don't even need to resort to psychoacoustics to explain that it makes sense to use a logarithmic scale rather that a linear scale which would make volume vary wildly in the lower notches and very little in the upper half.

I for one implemented a logarithmic volume knob in my commercial program that goes from -30 dB to +30 dB and it works just great!

Have you started coding a VLC solution?

Yup, I agree (obviously, considered my previous posts), however I feel to compelled to point out that more than a psychoacoustics phenomenon, it's simple explained by the fact when it's logarithmic, everytime you change the volume a notch, the ratio by which you change the volume is fixed, so you don't even need to resort to psychoacoustics to explain that it makes sense to use a logarithmic scale rather that a linear scale which would make volume vary wildly in the lower notches and very little in the upper half.

I for one implemented a logarithmic volume knob in my commercial program that goes from -30 dB to +30 dB and it works just great!

Have you started coding a VLC solution?

Nope sorry, too busy working on my commercial program to code on anything else.

Although it would be trivial to do if j-c didn't require that it would be made into a toggleable option. That's what I love about open source development, if you want something and make a good case for it you'll be told "cool, do it yourself". When someone asks me for something for my program I reply with a beta release containing the requested feature .

That's what I love about open source development, if you want something and make a good case for it you'll be told "cool, do it yourself". When someone asks me for something for my program I reply with a beta release containing the requested feature .

I'd imagine you're getting paid to make that beta though.

That's what I love about open source development, if you want something and make a good case for it you'll be told "cool, do it yourself". When someone asks me for something for my program I reply with a beta release containing the requested feature .

I'd imagine you're getting paid to make that beta though.

No not even, it's just that I know that it's in my best interest to listen to what my users want and accommodate my development schedule accordingly when they come up with good suggestions. Sometimes it's so trivial to implement I just do it right away and ask them what they think of the way I implemented it.

With VLC I get the feeling that devs are more into doing whatever they want. That would explain the fiasco of the 0.9.x interface.

With VLC I get the feeling that devs are more into doing whatever they want. That would explain the fiasco of the 0.9.x interface.

Sir, you are starting to be painful.

0.9.x interface is not a fiasco at all...
If we compare the number of people complaining to the number of people telling it is better (bigger number), and knowing the fact that people complaining are more vocal than people liking it, the 0.9 interface look is very much appreciated, especially among non-über geek population.

You don't like it? Deal with it, but explain at least why... Which you don't, btw....

About this thread about log volume, as I told you already a few times, the increase linear on the interface (and on the core, that has NOTHING to do with the interface, but you don't seem to be able to get it) doesn't mean a linear increase in power, nor in dB. It means a linear increase in the data fed to the sound driver, which is of course non-linear on most non-stupid drivers and OS.

Finally, since you know everything better, why don't you send a patch? And yeah, your software is probably so great and you listen to users, but do you know how many "user requests" we receive per day? Around 50... So not everyone's own request is fullfilled.

And yeah, VLC is totally crap, that is why there is no users using it...