If hijack supports it someday, taking control of the Knob when entering the Scroll mode, and giving it back on exit would be cool. In the meantime you could just let it scroll at a fixed rate or steal the remote's volume buttons.

If hijack supports it someday, taking control of the Knob when entering the Scroll mode, and giving it back on exit would be cool.

I think I can do that, no Hijack improvements necessary. I'm already binding the knob press, knob left, and knob right buttons, and also the front-panel left and right buttons (so I can detect rewinds/fast-forwards.) When I want them to go to the player, I just use the INJECTBUTTONS call and the player acts just as if the user had pressed the buttons with the player active. Quite handy.

So, I'd have to tweak the menu a little, but I could have a menu option to do scrolling, and when that's selected, the left/right buttons would scroll a particular field. Then you'd have to go back and switch out of that mode somehow. Or, yes, I could have other remote buttons do it, but I'm not sure how useful that is unless I then allow user-definiable buttons, which opens up another can of worms...

Really, I think automatic scrolling might be a better solution, at least in the first incarnation. I see the interface for scrolling fields getting ugly, especially if one wants to be able to scroll two different fields.

BTW all of this stuff takes a back seat to getting the program's primary purpose (lyrics scrolling) perfected.

Awesomeness.

Pull out RVA2 tags and use them to adjust volume?

Nice idea! In my opinion, per-song volume adjustment is better than dynamic compression because it preserves the volumes within each song. But a few obstacles come to mind:

1) Getting the info into the tag. Do commonly used rippers/taggers add this info? If not, could I forego the ID3v2 thing altogether and maybe leverage the data Toby uses in the Info:Seek tool somehow? Maybe that's a better approach since it's automatically done by the player anyway? We'd just need to know how to glean the peak volume from his data, if that's possible.

2) Setting the volume. I can send VolUp and VolDown IR codes, but that's yucky. There might be an ioctl() somewhere for me to set it, but I'd have to set it as a percentage of the current volume, or relative to some baseline volume or something... Maybe re-use something that was provided with the volume boost stuff? Not sure if there were userland hooks to that stuff or not.

Otherwise, this might be doable!

Getting the info into the tag. Do commonly used rippers/taggers add this info?

The normalize package will calculate them afterward and add them to tracks. I have no idea if an equivalent exists for Windows.

Of course, this isn't "really" what we want either. Really, we want an ioctl to tweak voladj, and to do true dynamic range compression (or expansion as needed) based on the true intent of the RVA2 tag.

Of course, this isn't "really" what we want either. Really, we want an ioctl to tweak voladj, and to do true dynamic range compression (or expansion as needed) based on the true intent of the RVA2 tag.

Okay. either I'm misled on my definition of "dynamic range compression," I'm not understanding the RVA2 tag's purpose in life, or both.

My definition of "dynamic range compression" is that the amount of volume boost/cut changes as the music changes. This is what voladj does.

The other approach is finding the peak of a given track and normalizing to that peak. Thus, two tracks which each peak at different decibel levels could be normalized such that their peak volumes (not their average volumes) match.

The ID3v2 reference states that RVA2 frames contain nothing but a channel number (front left, front right, etc.) and a 16-bit number which specifies how much to boost/cut the volume. It mentions "identification strings" which I guess could be hacked to represent certain points in the song, but that's kind confusing, and the spec doesn't really tell you how to use them. I'd be interested to see how this normalize package writes these frames, and how it magically decides where to boost/lower volume. Could you enlighten me what you're going after here?

Edit: Okay, Google led me to the Normalize web page, and the readme:
Version 0.7 and up can operate directly on MPEG audio files. An mp3 file is decoded (using Robert Leslie's MAD library) and analyzed on the fly, without the need for large temporary WAV files. The mp3 file is then "adjusted" by setting its relative volume adjustment information (technically, an "RVA2" frame is set in its ID3v2 tag). The advantage of this method is that the audio data doesn't need to be touched, and you don't incur the cost of re-encoding. The disadvantage is that your mp3 player needs to read and use relative volume adjustment ID3 frames. The normalize distribution now includes a plugin for xmms that honors volume adjustment frames. If you use an mp3 player other than xmms, you'll have to bug the author to support RVA2 frames in ID3 tags.

I see nothing about dynamic compression in there, really, it seems like raising/lowering the volume per-song... Not really Voladj-like, but more of a fixed +/- factor per song.. or am I reading that wrong?

I see nothing about dynamic compression in there, really, it seems like raising/lowering the volume per-song... Not really Voladj-like, but more of a fixed +/- factor per song.. or am I reading that wrong?

Unless the tag somehow contains moment-to-moment volume data for the song (instead of a single field representing a single relative volume number), then your assesment is correct. It's a single volume adjustment, not dynamic compression.

However, some would argue that this is better than dynamic compression.

The two things solve two different (but similar) problems. I'd like to see both implemented, and choose between the two.

My only problem with doing relative volume adjustment on the empeg is that if a song gets played at much more than +5db beyond where I've set the volume control, I'll start to clip it because of where my amp gains are set. Dunno how the relative volume offset handles that, does it always attenuate or sometimes boost?

2) Setting the volume. I can send VolUp and VolDown IR codes, but that's yucky. There might be an ioctl() somewhere for me to set it, but I'd have to set it as a percentage of the current volume, or relative to some baseline volume or something... Maybe re-use something that was provided with the volume boost stuff? Not sure if there were userland hooks to that stuff or not.


arch/arm/special/empeg_mixer.c contains the volume ioctls (both read and write) that the player uses. If you use these, then the volume_boost code will continue to work transparently in the kernel.

The big question is really whether you try to attempt absolute or relative volumes...
Absolute values can be found by looking at volume_entry volume_table[101] in empeg_mixer.c. Notice that 0dB corresponds to the 90th row. But I can't see how to make absolute values work - people would want to change their volumes anyway.

Relative values would suffer from the same issue that the volboost code suffers from - the volume steps aren't a consistent size across the whole volume range. In practice I think that this gives acceptable results though since most people will use their empegs in the linear region.

You will obviously need to do something similar to the volboost code and keep tabs on what adjustment you are making at any time, and removing the current adjustment before re-reading the volume (in case the user changed it mid-song) and applying the new one. This keeping tabs is made harder by the fact that any adjustment you make has to be kept within the hard limits of 0 <= adj <= 100. You'll have to detect when this happens and calculate what adjustment you *really* make in order to be able to undo it;

Assuming that you'd call this after reading the ID3 tags for a new track...sorry about the lazy syntax;

int current_adjust =0;   // initialised globally



volume_change() {

    // remove previous adjustment first. 

    vol = read_vol();

    vol = vol - current_adjust;  //current_adjust = 0 first time.

    write_vol(vol);  

           

    if (ID3_vol_tag) {

       vol = vol + ID3_vol_tag;

       if  (vol > 100) {

           // Hit limit - have to calculate real adjusment.

           current_adjust = vol - 100;

           vol = 100;

       }

       else

       if (vol < 0) {

          // hit the other limit...

          current_adjust = ( 0 - ( vol - ID3_vol_tag));

          vol = 0;

       }

       else {

          current_adjust = ID3_vol_tag; }

       

       write_vol(vol);

}

The other thing you want to consider is whether to cap at 90 (0dB) or not. You could read the users current cap setting in config.ini.
On the one hand, capping at 90 will still leave headroom for the volboost code, although this isn't really a factor since most people don't boost in mp3 playback (although they *could* if they really wanted!). On the other hand, if people are listening at a loud level then the ID3 based tag could run out of headroom. I suspect that the best thing to do is to cap at 100.

You will obviously need to do something similar to the volboost code and keep tabs on what adjustment you are making at any time, and removing the current adjustment before re-reading the volume (in case the user changed it mid-song) and applying the new one. This keeping tabs is made harder by the fact that any adjustment you make has to be kept within the hard limits of 0 <= adj <= 100. You'll have to detect when this happens and calculate what adjustment you *really* make in order to be able to undo it;

Hmm... The strategy sounds like it would work. I may play around with this some in the coming days and weeks.

Unless the tag somehow contains moment-to-moment volume data for the song (instead of a single field representing a single relative volume number), then your assesment is correct. It's a single volume adjustment, not dynamic compression.

It doesn't need to. You only need to know:
1) the volume of what you're playing now. A volume adjuster inline in the kernel already does (e.g. voladj).
2) the maximum and minimum present in the track, e.g. the current range
3) the target range (at which point you can calculate an adjustment factor)

The range compression can be dynamic: you need only to plug the necessary factor into whatever equation you're running on the gain in the real time play path, and update said value on a song switch.

My only problem with doing relative volume adjustment on the empeg is that if a song gets played at much more than +5db beyond where I've set the volume control, I'll start to clip it because of where my amp gains are set. Dunno how the relative volume offset handles that, does it always attenuate or sometimes boost?


Shouldn't be a problem - if the track needs +5dB to change it's level to that of the rest of your collection, then it shouldn't clip unless the rest of your collection clips.... Of course, if it were tagged as needing +5dB when it didn't, that's another matter!

Hopefully this code and the voladj code would work well *together*, with no need to choose between one and the other. This code would in effect normalise between differing tracks, while voladj would compress the dynamic range raising softer passages within a track.

The real question is whether voladj achieves it's compression without affecting the overall level of the track - ie by attenuating loud passages as well as raising softer passages. If if does, then the 2 methods should coexist perfectly.

If voldadj only raises softer passages, then in effect it would be raising the overall level of a track - and this would mean that in a normalised collection, tracks with the widest dynamic range would appear loudest.

Whichever way, I'm confident that the 2 can be tweaked to get the best of both. Maybe by tweaking the voladj parameters a bit, and maybe by manually lowering (in the tag) tracks that then end up too loud.

Hmm. Well I don't see myself bothering to do this unless there's some more understanding of how the adjustments are to be used. I don't really like dynamic compression because passages in a song that were meant to be quiet end up being raised up. If this were some kind of factor which just specified a fixed adjustment per song ("this song is X decibels too quiet on average, this other song is X decibels too loud on average") then I might be more inclined to try it out. I don't really want my program raising and lowering the volume hundreds of times per song.

2) the maximum and minimum present in the track, e.g. the current range

And I will repeat the thing I've already repeated until I was blue in the face:

The vast majority of tracks in your collection will have the same minimums and maximums (0% and nearly-100%) even though they sound like they're at different volumes.

The vast majority of tracks in your collection will have the same minimums and maximums (0% and nearly-100%) even though they sound like they're at different volumes.

Yeah. So if the ripper/tagger could pick out the *average* volume (RMS?) and provide a single adjustment per song so that the *averages* are constant, that might be more along the lines of what I would want...

Your program wouldn't be in the kernel itself, it would poke one value into the kernel, and let the kernel do the volume adjustment, like voladj does now, but essentially providing the upper and lower bound instead of the limited lookahead of the current voladj.

On the other hand a reread of http://www.unixgods.org/~tilo/ID3/docs/id3v2.4.0-frames.html#RVA2 suggests I'm wrong anyway.

You need an avatar where you're blue in the face.

I mis-summarized, you need also a mean volume precomputed. Your point stands on the data I just posted, but doing dynamic range compression by simply having a small number of precomputed values is possible. You just need different data than what I shared.

Rereading suggests if you just pull the RVA2 tag data out and do a fixed adjust once per track based on it, it will do what you want assuming you place the RVA2 tags with (the) normalize (package).

Never mind all the complicated stuff I suggested. I was wrong.

Not sure what gave you the idea that I wanted to do anything extra in the kernel. We'd just need kernel calls to set the volume, and per genixia's volboost stuff, we've apparently got that.

Rereading suggests if you just pull the RVA2 tag data out and do a fixed adjust once per track based on it, it will do what you want assuming you place the RVA2 tags with (the) normalize (package).

In that case, I will probably investigate this soon. I've been meaning to do a re-rip and encode session anyway... Might as well look into this first.

and per genixia's volboost stuff, we've apparently got that.


I wish I could claim all the credit...but the ioctls already exist in the stock kernel, I just hacked them around a little.

You suggested an ioctl. Nothing said *you* needed to be the one to write whatever was on the other end of it.

for dbrashear:

Now we just need to get him to use it for his posts....

Heh, I look like Violet Beauregard. Feel like it, too, I've been over-eating this last weekend. Ick...

I've got to put up a new avatar sometime soon, I need a better pic of me. That one's a few years and about 30 pounds ago.

I think a pan of cover art would be awesome, I've had that idea for a while now but didn't want to code it.

In reply to:

---

You need an avatar where you're blue in the face.

---

ROFL... I've often thought you needed an animated avatar of you turning red for FAQ posts.

Hi Tony,
Wow, this is excellent! Works great, had to enable notify=1 in my config. Now a few things i've ran into while using emphatic.

I have rows set to 17, and when i turn on the large font, the top of my screen gets scrambled up.

If you don't set the end time of the track, the program will instantly hide itself right after the last time stamp, hiding that lyric line.

And i guess the last thing would be, what do we have to get the empeg guys to get this into 2.0? It would be really neat to add the lyrics right in the song properties in emplode! It would remove alot of steps that are needed to get the lyrics perfect

Adding this feature to Emplode would be awesome. Especially for those of us that are a little over our heads technically. NOTHING is worse than knowing just enough to realize something is really cool but having no clue how to implement it.