Recording Enhancements Pack

[Mmmm]

The build in post#1 now only has remote support and changeable fonts as extras. If you look at vinylivo's patch he has also put in automatic gain control and histograms and some other things...

In the original Iriver firmware there was a ticking sound when you recorded with the remote plugged in... drpheel, is this what you are hearing? I can hear it with remote support and high gain levels.

[whatboutbob]

Mmmm: That's not it.

dr.pheel: Just for giggles, try resetting your config settings, and see if you can replicate the issue.  If that fixes it, kick off the metronome and test again.

Are you sure its not your mics? (just have to cross it off the list of possibilities)

[dr.pheel]

ok,

I am running yesterday's build now, and seem to be having no problems so far.

Mmmm:
it definitly had nothing to do with the remote cause I never use it. I also tried with using the metronome before recording again, and there was no ticking sounds so far...

whatboutbob:
it definitly didn't sound like anything with my mic was wrong.

it must have been some bug in that build I was using (and I think it must have been something about using the metronome before recording)

I'll let you guys know if there are any further problems.

thank you all - phil

[toolmanwill]

is it possible for someone to patch Mmmm's latest build with vinyl's patch for me as i cant get the utilities to work on my PC.
Thanx in advance to the kind soul!

[Mmmm]

Just in case anyone is thinking I've stopped working on this, I thought I would set your minds at rest..

I have finally, with much gnashing of teeth and pulling of hair, managed to work out how the gui system works and have managed to implement the WPS peakmeter into the remote....Hooorraaaaaaaaaaaaaaaaahhhh....

Now that I have managed this, the rest (implementing the recording screen on the remote) is the easy part!

So sometime this week (hopefully), I should have a commitable patch for remote support for the recording screen... ooh..it's so exciting.....   

I think I'll take the rest of the night off.... cool beers in the fridge!  ...Cheers!....

[vinylivo]

I just updated the AGC patch: http://forums.rockbox.org/index.php?topic=2841.msg20404#msg20404

[paulheu]

I have finally, with much gnashing of teeth and pulling of hair, managed to work out how the gui system works and have managed to implement the WPS peakmeter into the remote....Hooorraaaaaaaaaaaaaaaaahhhh....

But.. but I have had the recording screen on my remote from the start..

[Mmmm]

I have finally, with much gnashing of teeth and pulling of hair, managed to work out how the gui system works and have managed to implement the WPS peakmeter into the remote....Hooorraaaaaaaaaaaaaaaaahhhh....

But.. but I have had the recording screen on my remote from the start..

You mean with the patch in post#1 right?
The recording screen isn't implemented on the remote with the normal build yet!

What I meant is...
The patches in post#1 are hacks that won't ever get implemented into CVS, so you will always need to use a special build or a patch to record from the remote screen. They work fine but they don't mesh with the rest of the rockbox code very well (meaning that a peakmeter for the recording screen is all very nice but what if you want to use it in the rwps or for the radio? You just can't get it to work with my code...well, not without a total rewrite and downgrading of the current WPS code anyway..... So therefore not an acceptable solution).

I am working on a version that will work for any target, (without using any preprocessing(#if/#ifdef)) and blends in with the already present methods of using the display...much harder to do but I'm nearly there now!

It will be more flexible, robust and just generally easier to maintain/alter. Of course any non programmers won't notice the difference, it's just that more will be possible with the new code! It is so flexible that even if a player is introduced that has 3 screens it would automatically support the 3rd screen no matter what size it is! Without changing any code at all!!!!! [/advert] 

When I've finished, with a bit of luck someone will decide to commit it so that you no longer need a patch! (I get the feeling this will be the most difficult bit!)

I hope that explains what I'm up to a bit more clearly! 

When I do get it finished i'll post the patch/build here and it would really great it if everyone could test it, (if it works properly you should notice no difference whatsoever (apart from %pm working in rWPS). Then I can fine tune it just like I did with the hack patch to get it really perfect.

[petur]

When I've finished, with a bit of luck someone will decide to commit it so that you no longer need a patch! (I get the feeling this will be the most difficult bit!)

Nice to see you're writing code that is committable
 
The problem is I don't have a remote (actually the bigger problem I don't have time), so this will be hard for me to test before commit - I may have to trust you

[Mmmm]

Damn...there I go modifying your posts again....
I think I put it all back in place....

When I've finished, with a bit of luck someone will decide to commit it so that you no longer need a patch! (I get the feeling this will be the most difficult bit!)

Nice to see you're writing code that is committable

The problem is I don't have a remote (actually the bigger problem I don't have time), so this will be hard for me to test before commit - I may have to trust you

I promise I will test till I'm blue in the face.....
should I compile and test for all targets or are there just a select few that will do the trick?

[petur]

should I compile and test for all targets or are there just a select few that will do the trick?

depends on the changes, I always build for all targets to be sure... Now with the crosscompilers available it's quite easy to check...
Most important is that it works on the possibly used remotes (h1xx, h3xx,...)

[vinylivo]

Not shure if this is related to the enhancement pack or not.

There is a problem with automatic file splitting during recording if it should split at max. file size (max. 2GB FAT file size - 1MB). Yesterday I recorded a Jazz concert and this was the first time I didn't set auto time split and I really regret it now because the last quarter hour is missing. 
The recorded file is actually 2'147'475'500 bytes (3h22m) and this is 2047.992MB and NOT 2047MB as it should be. Really very very close to the FAT limit (only 8148 bytes left).
The bad thing is after this the jukebox didn't continue to record but shut down! There is a following file but the file size is ZERO. And I tried Scandisk and PC-Filerecovery and there is no lost data! 

Pre-recording was set to 20s. And I made the observation that if pre-recording is on not all the prerecorded bytes are counted for the file size display. You see this clearly if e.g. at 1min the file size is not 10MB as it should be.

I really have to find out what exactly happened here, I never want this again! And perhaps we should set the limits for max file size less critical, e.g. leaving 10 to 30MB left instead of just 1MB. This would be more save. Aaaah I really hate that I didn't restart the recording during the concert pause! But sometimes bad things happen...


Otherwise I tested my AGC implementation for the 'Live Limiter' preset and this worked fine. Good levels for the recording, some very occasional clips during fortissimo parts but that's no problem. The performance was very dynamic, sometimes more than 40dB from quiet to loud parts.

[Mmmm]

Now that I have managed this, the rest (implementing the recording screen on the remote) is the easy part!

Did I really say that???

I take it back! 

Might take a bit longer than I thought!...

Got it all coded but doesn't quite work as it should...hmmmm
I'll keep plugging away at it....

[vinylivo]

Not shure if this is related to the enhancement pack or not.

There is a problem with automatic file splitting during recording if it should split at max. file size (max. 2GB FAT file size - 1MB).

I found the bug. It's not related to the enhancement pack at all. The bug is in 'pcm_recrd.c' in function 'pcmrec_start()':

Line 644 is wrong:

Code: [Select]

    num_rec_bytes = 0;

it should be:

Code: [Select]

    num_rec_bytes = pre_chunks * CHUNK_SIZE;

to take the prerecorded chunks into account.

[petur]

I found the bug. It's not related to the enhancement pack at all. The bug is in 'pcm_recrd.c' in function 'pcmrec_start()':

Line 644 is wrong:

Code: [Select]

    num_rec_bytes = 0;

it should be:

Code: [Select]

    num_rec_bytes = pre_chunks * CHUNK_SIZE;

to take the prerecorded chunks into account.

That will be my bug then, as I did the prerecording

thanks for finding that one!