ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE. Software > Post New Requests Here

IDEA: edit decision list preparation for long audio files, subtle GUI...

(1/3) > >>

Hello all - I have an idea for a small programme, hopefully quick for the ninjas here....

It's kind-of an audio player, but with an additional layer of annotating/organising/editing what's being played

use case: - long source audio files (e.g. 3 hours) with multiple songs or parts of discussion/book etc etc
I want to prepare an edl (Edit Decision List) at work, listen/mark/name/reorder/join etc which creates a txt-based edl  file saved alongside (same name as) source audio file, then finally when I'm satisfied with the edl and how it plays, dump out edited waves with filenames as defined in the edl.

ideally run as portable executable without install (or at least the option to do that), run on any operating system from vista to current.. (I'm mostly in win7_64 but likely to change soon at work)

Interface must be small, minimal, (no big wave display etc). I.e. it's unobtrusive on a pc in an office at work, so these long audio files can be worked steadily through on headphones without much taking eyes off doing whatever boring office job, and without making the boss think you're doing anything much else.

Just non-garish display of time position (click for time remaining this track, time remaining whole file), track number+name, and then some transport (play/pause/prev/rew/fwd/next/repeat) and mark/split/join/up/down/ignore buttons, info button and file open/save/save.
click on the track name to type in a name.
click 'mark' to mark a point in a track. uh.. some method to unmark as well?
'split' to split a track at the most recent mark. actually, thinking about it, maybe split and mark can be one and the same...
'join' to heal/join a track to whatever precedes.
'move up' to move a track up the order.
'move down' to move a track down.
'ignore' moves a track to the end of the edl and calls it e.g. ignore01, ie a file won't be created for that track when they're all output - renaming it will bring it back into the output list (and put it back before all the ignores).

This kind of simplicity is found on e.g. old portable minidisc recorders. there is no visualised element, just listening and not-too-heavy thinking, but full capability to make a complex non-linear TOC (Table of contents i.e. an edit decision list on a minidisc) from whatever originally got recorded. e.g.

cuts/joins must not involve encode/reencode, fadeout, crossfade or anything else - it's pristine/bitperfect and could be rebuilt with no loss.

Perhaps ideally cut/join at zero crossings

must have mono/stereo capability of 8 to 32 bit samples, and any sample rate supported - ie very basic system sounds to very very high quality audiophile/studio sound. I'm looking at pcm wav files initially, don't really care about other formats (e.g. i believe there are issues about trying to spilt mp3s at arbitrary positions without alteration - it's unnecessary extra complication for v1.0).

In a concession to actually being on a computer with a nice big screen an info button might open up a bigger overview screen showing the full edit decision list, track names (renamable?) etc, maybe click to play. maybe the edit times might be editable.. if there's been a lot of joining/moving then this screen will be interesting, could be several lines of edits for one 'track'. also this screen could be useful for getting out of a jam, or doing some 'undo'... i'm not sure about this..

'open file' chooses the source audio file to make an edl for: opens file and immediately creates an edl file for it.
'save edl' saves the current progress of building the edl file - closing the programme will bring up this as a question.
'output files' makes new wavs according to the edl. [dialogue box to ask for where to save to, and also if there should be a common prefix. add track no etc..]

clicking 'repeat' cycles between 1,all,none,(shuffle? - plays all non-ignored sections)
clicking 'rew'/'fwd' cycle between several speeds of audio scrubbing with the intention that you can quite accurately place a mark point by ear, but also fairly swiftly wizz through ten minutes of dross..

Possibly, in a further concession to being on a computer with a mouse, a very small (but I suppose fairly wide) clickable position indicator line representing the whole file, to allow for very rough navigation, so you'd not need to hold 'fwd' down for ages to get two hours into a three hour file...

v2.0, ie things that might be sweet for some folk but i don't care about and will probably just add complication:
- recording capability,
- other formats of audio file,
- edit the times in the edl overview window
- save wavs can save in other formats too (more palaver, metadata etc?)
- crossfade joins (and associated palaver, curve shape, onoff etc)
- bring multiple source files into one edl (more associated palaver, where does the edl get saved? different formats?)
- output xml based edl - maybe compatible with some video e.g. FCP  ones?

...tumbleweed.....   :-[

I guess this didn't look very snackish to anyone, maybe it's the closeness of NANY... maybe my eyes were bigger than my stomach!

So I'll try and break it dow into suggested snacklets in order of desire... maybe a little more snackish.. any of these look too chewy?

Basic Player:

1) a simple audio player - maybe you already have some code for this - can it handle large/long/high resolution files? ideally small, portable

2) a simple gui. a very simple gui, play,pause,back buttons , display time readout.

3) add fwd/rew winding/(audio scrubbing?) buttons for navigation - the desire here is to be able to position a point very accurately, so slow scrub - but also they're big files, so fast wind available too.

Track Marking:

4) add ability/button to drop trackmarkers at desired timepoints, held in an array of 'tracks' that each have a start and endpoint- this change implies gui display will now show what 'track' we're now playing, back button now goes to last marker (and can go to previous track too if repeated presses fairly close together), new 'next' button. default condition is that track 1 begins at the beginning and ends at the end of the file

5) add ability to snap these markers to zero crossings, (or chunk boundaries for mp3?).

6) a 'join' button that will join the current track (as defined by the position of playback) to whatever is before - at this point this is simply the removal of a track marker (and line/row in the array, and revising the endpoint of another line, and consequent renumbering of later tracks in the array)

7) add ability 'Save EDL': save array as a simple text file using name of original audio file and different extension e.g. .edl the text file format is to be pretty simple, so can be human-edited without too much difficulty. I suggest the track numbers are not written in the file - use lines/rows instead. Although the idea is that the file is only manipulated by the program, at least initially, otherwise there's lots of odd cases to handle, eventually it will handle a bit of manual editing, and this means a human can remove a line without doing a full renumber.

8 ) now when an audio file is opened in this program it will look for a matching .edl file and load it into the array. At this point not huge checking for validity of file.

Audio dump:

9) a new ability 'Save Audio Files': to dump all audio out to individual files according to the trackmarkers. original file name with trackmarker suffix added. The cuts must be non-destructive/flawless/bitperfect.


10) add ability to name these 'tracks', for the track currently playing (as defined by position) click in the gui display and either dialogue box or directly type the track name, also held in array, also saved in file - track and name are shown in gui display. Now name is used in addition to number suffix when dumping audio out. (some kind of dialogue box/setting about file naming convention?)


11) add an 'Ignore' button so that the current track (as defined by playback) is renamed '#Ignore', effectively it's just a shortcut to give the current track the name '#Ignore' The segment stays where it is in the Array/File though. it is then NOT included in the audio dump and regardless of what row/line it is in the list it is only played after all the other tracks. 

12) if a human edits a file, they may leave some time periods of the original audio file unused. I suggest they're recreated by the program as lines in the array/file in the appropriate chronological position named as '#Ignore'.

13) renaming (or blank naming) an '#Ignore' track reinstates it. when this happens it might be worth a dialogue box flagging up what track number it just became


11) ability for re-ordering: 'up' and 'down' buttons move the current track (as per play position) up or down the running order: here we're telling the program to play a segment of audio out of its original order. also a human can move a line up or down in the .edl file. This implies:

11a) the 'join' button - having moved tracks about a bit the 'join' button may now be asking to join two segments of non-continuous data - if so these two joined segments must still maintain their individual lines in the array/file with start/end positions but there needs to be a standardised flag on the second segment indicating '#joined to previous' (actually that could be in the 'name' part couldn't it, as it inherits the name from the first segment). When reading a file the track numbering would need to skip over these 'joined to previous' lines. In playback the user sees it as one track which plays through the join seamlessly. If one of these multi-segment tracks gets moved up or down, all of its segment lines must move with it!


15) some levels of undo, so changes can be rolled back....

Large file search

16) add search position/slider/bar/thing for improved navigating very long files

Further elaborations

17) handling bwf files using original meta data and putting it into the dumped audio files

18) play-engine sweeteners like 'repeat/shuffle', any other shenanigans from previous post

I do somehow understand what you want, but this aint a coding snack, this a real full application with alot of user specific wishes that you are talking about.

Free coders like me scare all your wishes and specifications away.

Hi KodeZwerg

ahhh, ok.. not a snack - perhaps it could be moved to a more suitable part of the forum?

I wrote a lot in the hope to be specific and clear, didn't want to scare anyone away  :D

@mutetourettes, the forum you picked is good, how specific you are is good, if someone answer this call.... lets see


[0] Message Index

[#] Next page

Go to full version