Rockbox General > Rockbox General Discussion
"Tagged" EQ PreSets - Possible?
KindOfBlues71:
--- Quote from: Llorean ---This offers less flexibility (files are harder to move, for one thing, you can't rearrange your collection) than simply putting them beside the original file.
There's no reason to add limitations to the system just because iTunes has a silly structure. We can't, or shouldn't, spend forever working around it, and sometimes it's better just to say "they'll have to figure out which files are their songs for this one." If there was a graphical UI for creating these individual EQ addition files, it could put them in the right place anyway.
--- End quote ---
I personally hate the iPod directory structure and how it re-names files. As I understand it, one reason for it is to cut down on seek-times/hard drive usage. That's one reason why I've stuck w/ the iPod file structure.
Back to the topic, what isn't flexible about giving users the option to either store the eq/config file in a single folder or in the directory containing the files to apply the settings? Those are the options Rockbox users have for Playlists, albeit from two different menus - Playlist Catalog and Playlist. If the developers were concerned about users restructuring their music directories they wouldn't have made the default location for a dynamic playlist the root, nor the default location for saved playlists the Playlist folder.
--- Quote from: Llorean ---I would take Chronon's idea one step further, personally, and apply all EQ modifiers in the path.
If you had /music/rock/ACDC/Back in Black/song.mp3 and there was a rock.eq in the rock folder, and a Back in Black EQ in the album folder, they should both be "added" to the static EQ, because the Rock one is there for your preferences for the genre, and the album one is there to correct for oddities in mastering the Album. The offsets should be cumulative.
--- End quote ---
I disagree with applying EQ cumulatively. If you take the time to EQ a specific album to your liking, why would you want anything to alter it? If you're listening to an artist where the Rock EQ is applied and then play a track from the Back In Black album, all EQ settings should be completely changed to the Back In Black EQ only, not a cumulative EQ of both.
Chronon:
--- Quote from: KindOfBlues71 on June 04, 2008, 01:57:18 PM ---I personally hate the iPod directory structure and how it re-names files. As I understand it, one reason for it is to cut down on seek-times/hard drive usage. That's one reason why I've stuck w/ the iPod file structure.
Back to the topic, what isn't flexible about giving users the option to either store the eq/config file in a single folder or in the directory containing the files to apply the settings? Those are the options Rockbox users have for Playlists, albeit from two different menus - Playlist Catalog and Playlist. If the developers were concerned about users restructuring their music directories they wouldn't have made the default location for a dynamic playlist the root, nor the default location for saved playlists the Playlist folder.
--- End quote ---
Well, this whole idea still needs to be fleshed out properly. I can see that it would be fairly straightforward to simply follow the path of each file in a playlist to look for EQ modifiers. However, sensibly accommodating Apple's file storage scheme adds some difficulty. You are advocating for storing the EQs all in one place. But this doesn't give Rockbox an easy way to tell if an EQ needs to be applied to a given file or not without reading the file lists in each EQ that you have stored there. It sounds messier and slower than a method that simply groups the EQ settings with the files that you want altered.
--- Quote from: KindOfBlues71 on June 04, 2008, 01:57:18 PM ---I disagree with applying EQ cumulatively. If you take the time to EQ a specific album to your liking, why would you want anything to alter it? If you're listening to an artist where the Rock EQ is applied and then play a track from the Back In Black album, all EQ settings should be completely changed to the Back In Black EQ only, not a cumulative EQ of both.
--- End quote ---
I can see why you might prefer that.
From the other side of the issue, relative settings (modifiers) would allow a presumptive .eq file to act as a filter. So I would imagine storing a .cfg with absolute settings that correspond to my best assessment of a flat response for the given headphones that I'm using. This is how I store my EQ settings currently -- I have a .cfg for each pair of headphones that I use with my DAP on a regular basis. This serves as a starting point and you could further apply filters to this to suit individual files without losing your reference point for the given headphones you're using.
Anyway, it seems like soap has some input regarding this whole issue so we should probably let him weigh in on all of this before we get too ahead of ourselves.
soap:
I'm actually forgetful about what my main "beef" was with Llorean and Chronon - so why don't I just issue an apology?
If we're bar-talking this subject, though, here are my thoughts:
* Equalizer settings stored in a .cfg file should be absolute.
* Equalizer settings stored in a .eq (for sake of conversation) file can be relative.
* Perhaps a menu toggle to make .eq files relative (cumulative) or absolute.
* I am attracted to .eq files being searched for in exactly the same hierarchy album art is searched for.
* This solves the iPod database issue.
* This maintains only one "pattern of association" to learn.
* This allows you to tweak EQ settings at exactly the granularity you desire.
* You can have your "rock" .eq file associated with an album (copy rock.eq to AlbumName.eq) while still being able to have a track-specific override if you really want to peak to 'White Rabbit'.
* I do not see the need for having a .cfg EQ setting (hardware), an album-art-style .eq EQ setting ("Back In Black"), AND another .eq EQ setting. (Rock)
* Perhaps a second example of where this would be useful could sway me (as if I have any say), but I agree with KindOfBlues71 on this, and do not see how the system I outlined above conflicts with the usage pattern Chronon describes in his response to KindOfBlues71.
EDIT: OH - THAT'S RIGHT! I was arguing semantics - a stupid thing to do!
Chronon:
Nicely organized. I think this satisfies all of the concerns so far. No arguments here.
Llorean:
If you have a .cfg EQ, an album .eq, and a genre .eq, it means that if you switch headphones to ones that are say have much lower bass, you don't have to reconfigure every single individual EQ to take this into account, you just tweak the hardware EQ and you're done.
Also, many people have genre EQs (why do so many players come with them naturally?) yet Febs suggested there may be badly mastered albums or tracks that need correcting. You could always, I suppose, have the individual album one override the Genre one, but it seems to me ideal to be able to preserve a "flat" version of the album by having an individual album .eq, then if your "rock" tastes change you don't have to redo the overall "Rock" EQ, plus every individual album EQ you've already created for problematic ones.
It just seems having them cumulative the whole way down means "if the situation changes, you need to make the fewest possible changes to your .eq files" so I don't see what the negative of it is in response to that. All I really got was an "I wouldn't use it, so it's not necessary." Personally *I* wouldn't use it, but I still think it's better than having them replace each other, so only one is active. Why even do cumulative to the hardware EQ if you're going to do it like this, why not just say all .eq files must be explicit?
The only apparent disadvantage of cumulative EQ is that it might confuse some people at first. But there's nothing you can accomplish with explicit EQ that you can't with cumulative, while cumulative would allow you much more freedom for adjusting the sound of your whole collection as tastes change or other needs change, while having to alter an absolute minimum of files.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version