- Status Closed
- Percent Complete
- Task Type Patches
- Category Music playback
- Assigned To No-one
- Operating System Archos Recorder
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#7747 - (limited) replaygain for archos recorder
I’ve hacked up (limited) replaygain support for my archos recorder using the MAS digital volume control matrix.
Limits:
- The overall (Track/Albumgain and Preamp) maximum “gain” is about +18dB
- The “Prevent Clipping” option does nothing
Cause for the limits:
The MAS DVCM can only be used to attenuate, so there shouldn’t be any clipping to prevent. Also, to simulate gain, I have set the +0dB (don’t apply replaygain) mark to -18dB…
I’m not sure if the Settings are correctly applied on Boot - the code says “they should”, but I couldn’t verify it.
To do:
- The replaygain settings of the new track are applied when it’s about to be sent to the MAS, not when the MAS will actually play it. So there could be a split second (depending on the mp3 bitrate) at the end of the current track played with replaygain settings of the next track.
- The analog amp in the recorder should have +5.95dB gain available somewhere, that would improve the chance to compensate for the “new 0dB” point.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Ok, I fixed the issue with the loading of the sound settings - the attached diff is complete with the fix for said issue.
Removed “noclip” code since it won’t ever make sense.
Removed “Language file updates” - the updates removed a restriction on language files for the Noclip option.
Reworked preprocessor directives so that this replaygain support is only built on hw-codec-platforms
Modified the application of replaygain to use 64-Bit Multiplication less often. I’ve replaced it with Bitshifts and Binary operations where I could.
Moved back to using 64-Bit multiplication because I wasn’t able to produce the correct values via bitwise operations.
updated diff to apply to SVN Revision 15913.
Found out, that the new MAS Replaygain settings are usually applied some fractions of a second into the _next_ track, so that switching from a silent track to a loud track will play a little bit of the Loud piece at a great volume and then lower the volume to the replaygain set value…
For my part the analog amp doesn’t need to be cranked up, I can manage with what it does…
Updated to apply to SVN Revision 16182.
As amiconn states in http://www.rockbox.org/irc/reader.pl?date=20080130 the audible delay in applying replaygain settings probably occurs when a track change happens during rebuffering. In that case the MPEG-thread is busy with bit-swapping the data for the MAS - the bit-swapping can take up to ~65ms, add other delays and you have the audible volume change happening maybe 100-200ms into the new track.
I’ll experiment with pushing the analog output, but clipping is possible with it - I’d like to avoid that…
Just another update - I found that with replaygain5.diff the volume would not be the perceived “correct” one in some cases. This is because it only updates on the “track change” event - but there are some other events that should trigger “update_replaygain()”, e.g. when resuming playback from stop or off…
Since I’ve yet to experiment with analog output and still have to see if replaygain gets updated correctly in “all” cases, this probably won’t be the last comment here.
Checked in on my Patch after about 1200 SVN revisions… What a mess :/ Will have to rewrite large parts, because the structure of firmware/sound.c has changed a lot. Am planning to do that - but it will take some time.