The vi(m) text editor...
Google is not my friend here...
I have already found out that it is possible to save a pure text file without the '0x0A' newline character at the very end of the file but I can't find anything on the next question.
I have written a raw audio file to quantised pure text converter.
This converts a 0 to 255 level binary file centred on 128, to a 32 to 126 level text file of the same audio centred on 79. That is the minimum is a space character and the maximum is a tilde character centred on 'O'.
The file a a pure flat file of random characters and can be a minimum of 8000 bytes in size but could be virtually unlimited above that.
Q: Is there a line limit set in vi(m), and if yes, can it be altered?
(Gedit is OK with 8000 ASCII bytes but adds a newline at the end...)
TIA...
Hi Wisecracker,
From memory (a dim and distant one) there was a limit of 1023 characters plus a new line. But then it was 16bit cutting edge technology, I would have imagined that things would have moved on.
Regards
Gull
---------- Post updated at 11:12 PM ---------- Previous update was at 10:52 PM ----------
Hi wisecracker,
I've just tried vim version 7.2.411 with lines of 10k and no problem.
Gull
I think I'm missing the point.
What editing commands do you want to apply to the long, incomplete line of data in your raw audio file(s)?
If there could be nul (ox00) bytes in there; vim will need the -b option to correctly read in the entire record. - assuming I understand what you are asking. And yes, vim can handle file records longer than LINE_MAX.
However, modifying a single huge binary string with an editor like vim is not easy. I use UltraEdit with hexedit set on. UltraEdit is not available for OSX, AFAIK. BLV may be. I dunno.
Hi Don..
I am working on a shell script, Arbitrary Audio Waveform Generator. I created the audio file in pure text mode to check if there was any major degradation of a sampled 1 second audio signal compared to the original 8 bit binary version. Yes there was/is very minor degradation to the ear and obviously because there is less swing in the overall amplitude the output level is less. I considered that OK for this kids level project.
I therefore want an editor that is able to create very large flat text files and save without a newline at the end...
However I might create my own simple version and inlude a simple on window display of this waveform too at the same time as creating it. I don't know how hard this will be in shell scripting but I willing to attempt such an oddity.
Hi Jim...
There will be NO character values between 0 and 31 decimal and 127 to 255 inclusive, so no need for a hex editor, (I already have a hex editor on my desktop)...
Yeah I know, a strange requirement but my niche is creating simple measuring gear HW and writing code to suit. As my language of choice is *NIX bash scripting then I am going down that road...
You can create huge files with no newline characters with:
printf '%s' "$waveform" "$waveform2" ... > file
and add as many more waveforms to the end of that file as you want with:
printf '%s' "$waveform3" "$waveform4" ... >> file
I repeat: What editing commands do you want to apply to the long, incomplete line of data in your raw audio file(s)?
You may well be able to use portable printf , cut , and paste commands without needing to worry about text editors' desires to work with lines terminated by a newline with lengths no longer than LINE_MAX bytes.
1 Like
Hi Don...
Hope this lot is lucid...
There was just a few to be manually done...
Go to column <n>. (Row will always be 1).
Delete character and replace.
Save and exit without a newline...
cut and paste duly noted...
However; I am working on an on-window full screen text editor that displays the waveform and changes any selected character and redraws the new waveform and places it into a variable and when finished this variable will then be played through SOX.
This will have the option of saving it using printf or just losing it on exiting the code...
The waveform will be approximate as viewed as I can only obtain 47 rows from the MBPs default terminal and when multiplied by 2 gives 94 levels inclusive. The 94, (95), level accuracy is maintained however, just the image is not so accurate.
I hope to have a DEMO idea working in the not too distant future...
All in text - EEK!