My knowledge of programming is virtually nonexistant, so if this is a patently ridiculous question, I apologize in advance.

My second most wanted feature (after Voice Recognition) that we never got in our empegs would be the ability to assign specific equalizer presets to specific tracks.

The assignment would be optional. If there were no EQ preset assigned to a track, the track would default to whichever preset was currently the "working" EQ preset.

I would be perfectly happy to sacrifice one of the less-interesting data fields in the database (like "copyright", "original", or even "PIN" or "BPM") to this task.

Would some clever HiJack thing make this possible?

tanstaafl.

Would some clever HiJack thing make this possible?

Hm, Mark typically evaluates Hijack features based on how easy they are to do from a user app (since the kernel *could* theoretically do anything a user app can, but the kernel's memory footprint is very important.) I would say that based on some stuff I already have coded up and *almost* ready to release, EQ presets per song is very very doable from a user application. Once I get my first release out the door, I will strongly consider EQ presets per song.

One thing, though... Instead of database fields, would ID3 tag values be okay? I haven't cracked the player database yet, and as far as I know, PIN and BPM aren't available from FID files, so as of right now if I were to use a field for EQ, it'd have to be an ID3 field (and most likely an ID3v2 field.)

The feature has been discussed before, yes. I had a simpler, more manageable version of the idea in mind: Each song could have different amounts of bass and treble modification based on something in the comment field.

Mostly because I don't think most people want to painstakingly set up an entire host of EQ presets for each group of songs. I'd much rather just "tone down the bass for this album, tone down the treble for this album." etc.

One thing, though... Instead of database fields, would ID3 tag values be okay?

That idea has good points and not so good points.

I don't think any of the ID3V1 fields are "available" for this usage, at least not in my system, I use them ALL and would not willingly give any of them up.

However, there are 40-odd additional fields defined in ID3V2 (in addition to the 'V2 fields that duplicate the 'V1 fields) and I would be happy to sacrifice any of them. The down side being... there is no way to edit the data contained in any of those fields in emplode. This wouldn't be a deal-killer, though -- chances are, as Tony (the other Tony, not you) points out, these EQ presets would be applied an album at a time, and it would be easy to do so with MP3TS or a similar program. It does mean, though, that instead of just fixing and rebuilding the database to change the EQ settings of a song or group of songs you would have to delete those songs from the player, modify their tag information, and then reload them.

I could live with that.

tanstaafl.

It's not really feasible. The problem is that only the player software knows what hex values to apply to the DSP to realise any given EQ setting. The algorithm for calculating these values has never (to the best of my knowledge) been publically released. It isn't in the DSP reference manual. That manual refers to a DOS executable that is used to calculate the values. I don't know how the empeg guys implemented it within the player software, but I suspect that they were given further information under NDA.

Now I guess that you're wondering how the bass/treble works. Simply put, I cheated. I added debug code into the kernel and watched those hex values as I played with the EQ. I managed to discern which part was responsible for the dB parameter, and obtained the hex values corresponding to {-6, -5, ..., 3, 4, 5} dB and plugged them into my code. I then set the frequency and Q factor appropriately and obtained the rest of the values. I still have no idea what mathematical relationship exists between all those values.

A look up table works for the bass and treble. In fact it is probably more elegant than calculating the values - the table is very small and fast whereas the calculations would probably need to be floating point or, in kernel land on a non-floating-point-capable CPU, a fixed point approximation of floating point, ie computationally expensive.
However, a table is not appropriate for doing the whole EQ. Firstly, the table would need to be absolutely huge to describe every possible setting for a band. (~17000 frequency settings x 500 Q factors x 50 (?) gain values). It's not even going to fit into memory. I suppose that you could limit the potential values, ie making the EQ more discrete and less continuously variable, but the table would still be too big for anything remotely usable and the EQ would still be crippled. Secondly, you'd have to find some mug willing to sit in front of their empeg twisting the knob and entering all the hex values into a speadsheet, because you know that I'm not going to do that!

Changing bass and treble per track should be possible. It should be fairly trivial to add an ioctl to hijack to allow a userland to set them explicitly. This would allow emphatic (or any other userland tag-watching program) to set bass and treble parameters at will.

Changing bass and treble per track should be possible. It should be fairly trivial to add an ioctl to hijack to allow a userland to set them explicitly. This would allow emphatic (or any other userland tag-watching program) to set bass and treble parameters at will.

I think he was asking to change between EQ *presets* not (or the way I read it, anwyay) change to specific EQ params. The former is very doable.

Couldn't a bit of this be dealt with through the "genre" tag? I mean the basics at least? By parsing the tag and choosing the EQ preset based on that?

Couldn't a bit of this be dealt with through the "genre" tag? I mean the basics at least? By parsing the tag and choosing the EQ preset based on that?

Certainly, if the genre is a good enough indicator of what EQ one wants applied. If I ever implement something like this, it'll probably be flexible enough to say "when ID3v2 tag or FID field X is this value, apply EQ preset number Y" so I don't have to pick a particular tag or field.

However, there are 40-odd additional fields defined in ID3V2 (in addition to the 'V2 fields that duplicate the 'V1 fields) and I would be happy to sacrifice any of them.

There is a whole set set aside specifically for user-defined purposes. Any field that starts with X, IIRC, so that'd be 26^3 fields. I that that'd probably be enough.

Couldn't a bit of this be dealt with through the "genre" tag? I mean the basics at least? By parsing the tag and choosing the EQ preset based on that?

I'm sure it could, except it's precisely what I would NOT want to do.

My system sounds great for any genre. It's only specific albums within a genre that I would want to alter. Just because it's "Rock" doesn't mean I want to turn up the bass. I might want to turn down the bass on one specific album, but not change it for most of my collection.

For instance, let's say I've got my system sounding perfect with the hijack Bass adjustment at +4. But for Madonna's "Ray Of Light" I want the bass turned down two notches. So I would group-select all the tunes in Ray Of Light, and in the comment field and add something like "@BASS=-2".

My system sounds great for any genre. It's only specific albums within a genre that I would want to alter

Well, for the way I envision this feature being implemented in my program, it'll be just as easy to do with the album tag as the genre tag. At least to change EQ presets. Bass/Treble are chosen from the Hijack menu so that'd be tougher to do without some userland hooks.

Yeah, but only the player has any concept of 'presets'. The DSP only has a concept of 20 bands of EQ. ie, we cannot tell the DSP to select preset X, we have to tell it each and every parameter.

One thing that I had completely forgotten about, and now can't find; That big monster dynamic data partition thread might tell us about the way that the EQ settings are stored. I can't find it though - I can't even remember the title.

Anyway, if the player stores the EQ presets as the DSP hex parameters then we're golden. An application would simply have to index into the partition to the correct preset, read the 20 bands worth of parameters and call the (pre-existing) kernel ioctls to write them to the DSP. I believe that no changes would need to be made to the kernel to do this, and that bass/treble would continue to work transparently as they do currently, ie overlaying the top 4 bands. This would be ideal.

Anyone know where that thread went?

Yeah, but only the player has any concept of 'presets'. The DSP only has a concept of 20 bands of EQ. ie, we cannot tell the DSP to select preset X, we have to tell it each and every parameter.

Ummm... I wasn't going to get quite so sophisticated as to write to the DSP, I was kinda thinking along the lines of just injecting button codes to select EQ presets via the player menus. Selecting EQ's might take six or seven button codes max, and it might take the player all of one or two tenths of a second to make the change once the codes are received. To hide the ugliness of the menus coming up, I can hide the player's screen (by keeping a copy of the last player buffer before the change onscreen instead) so all the user will see is a fraction of a second of the screen freezing.

I'm already doing all this with visual changes (with very nice results so far.)

I don't think any of the ID3V1 fields are "available" for this usage, at least not in my system, I use them ALL and would not willingly give any of them up.


Eeeewww... replying to my own post. Tacky...

After thinking about it a bit, I agree with Tony F., use the comment field. If the first character in the comment field is @ (or some other character you would not normally expect to start a sentence) then the program would expect the next two characters to define which EQ preset to use. The remaining 27 characters (in the 'V1 tag; 252 in the 'V2 tag) would be used for comment. If there is no @ in the beginning of the comment field, then that track would default to the currently active EQ preset.

This has the advantage of being usable in emplode without having to reload the music; or being usable in MP3TS for mass changes, although that would require delete and reload.

tanstaafl.

It would have to be more than just @ because that might already be a normal part of the comment field in some weird cases. You'd need a more unique identifier string that was more characters long. Like @EQPreset=XX, or <Equalizer=XX>, or HijackEQ=XX or something.

And I'd still rather see a Bass/Treble addition/subtraction rather than an EQ preset select... I suppose we could do both...

You'd need a more unique identifier string that was more characters long. Like @EQPreset=XX, or <Equalizer=XX>, or HijackEQ=XX or something.


I disagree.

Every character you use takes one character away from what you have left for comment.

Nobody is likely to start their comment with a "@" character, and if they did, then the two characters following would not likely be valid EQ preset indentifiers, so that track would just default to the "normal" EQ preset just as if the comment had started with something other than "@".

I want the EQ preset identifier to be as unobtrusive and low-impact as possible. I actually do use my comment field -- probably 80% of the nearly 10,000 tracks in my player have the comment field filled out.

tanstaafl.

I propose @EQ=X, @HJB=YY and @HJT=YY. I can't think of anywhere in real life where those strings would crop up. We can describe the EQ presets as a single hex character. Theoretically we could do the same for bass/treble too, but it would be unwieldy - having to map a number {-6 <= x <= 6} to { 0 ... F } isn't very user-friendly.