I have been stalking this great site for ages. Today I finally decided to create an account when I got stuck on a problem.
My problem is rather basic vlcj executing. I have a program running as an audio player. It is all done except for one problem I cannot seem to figure out.
When someone tried to play a song with a 'é' (e with acute) in the filepath, it seems to translate wrong into the system of vlcj.
Example:
I run:
mediaPlayerComponent.getMediaPlayer().playMedia("file:///C:\\test.mp3");
//(where mediaPlayerComponentis my is my local instantiated
// EmbeddedMediaPlayerComponent)
And this plays fine. But if I run:
mediaPlayerComponent.getMediaPlayer().playMedia("file:///C:\\é.mp3");
It does not run anything.
If I call startMedia instead of playMedia, the boolean return value is false.
I also tried it without the 'file:///' in front of it, this doesnt functionally change a thing, except if I kill the program, then I get a 'libdvdread' error messages such as:
libdvdread: Could not open C:\?.mp3 with libdvdcss.
So to make the question short and sweet: How do I supply the correct 'mrl' to make vlcj play my 'é.mp3'. And/or which MediaOptions are needed to parse the correct encoding (I am assuming my error is here?)
Preemptively sorry for not supplying an SSCCE, I do not think it will be relevant.
Thank you for your time.
After some interlude I finally found out what went wrong. Apperantly, under windows international characters arent really parsed very well into VLCJ. By adding:
<jvmarg value="-Dvlcj.log=DEBUG>
to my ANT-run script, I suddenly could play files with an e-acute. Apperantly the decoder of the JVM is finalized when initializing.
Hope this helps someone :-)
This is transparently handled in vlcj 2.4.0 onwards by detecting local filenames that contain Unicode characters and converting those filenames to percent-encoded file URLs.
So with current versions of vlcj you should be able to simply pass your filename containing international characters directly to mediaPlayer.playMedia(...).
I found the solution here:
https://github.com/caprica/vlcj/issues/415
This work for me on mac and on windows (vlcj-3.7.0) :
public void play(String mrlPathFile) {
// URI encode for avoid non ascii character problem in windows!!!
mrlPathFile = new File(mrlPathFile).toURI().toASCIIString().replace("file:/", "file:///");
mediaPlayer.playMedia(mrlPathFile);
}
I this could help anyone :)
Related
I've looked at JLine, Lanterna, and others, but I'm not seeing a simple way to find the current caret position in the terminal with these tools. I've looked at a number of escape codes, tput, etc. But, I'm looking for the easiest way to get the current column and row where the caret is located with Java. Maybe I haven't found the right call in these libraries...
What's the easiest way to get the row and column of the caret in the terminal?
I'm looking for a pure textual library so that I can re-write the buffer. I'm aware of ansi escape codes and how to manipulate them to produce the effects I'm after. What I'm trying to do is make a Java prompt library in the vain of Inquirer.js for Node. It has a number of simple ways to get info from the user (lists, questions, split lists, etc). All of it text -- so all of it without a UI, and so non-swing. I don't want swing, I just want a decent terminal UI experience.
Edit2
With the http://docs.oracle.com/javase/7/docs/api/javax/swing/text/Caret.html Caret Interface, you can create a CaretListener Object in order to find a caret position.
So you would have to create a new CaretListener that responds to the GUI, with the getDot() method.
This might help... with code anyway.
http://bestjavapractices.blogspot.com.au/2011/11/get-current-caret-position-in.html
Now at the moment that would only work on a GUI/SwingComponents and I'm not sure if that would work for a terminal application ,which is what you want, where I assume you would be using command line arguments and such to get things to work.
I don't think that you could do this as I think the terminal is really just printing out the output, but I will keep checking for a little while anyway.
If you could tell me what you are trying to use the caret for that would help in my efforts.
Hope this helps.
If it doesn't you may need to look through some more Text Toolkits, such as
JCurses - http://sourceforge.net/projects/javacurses/
Charva - http://www.pitman.co.za/projects/charva/index.html
Current version of Lanterna can read the cursor position using ANSI CSI: https://github.com/mabe02/lanterna/blob/master/src/main/java/com/googlecode/lanterna/terminal/ansi/ANSITerminal.java#L266
And here you can find simple Java solution how to send the ANSI command and read from System.in reported cursor position.
How to read the cursor position given by the terminal (ANSI Device Status Report) in JAVA
So I'm working with last.fm API. Sometimes, the query results in tracks that contain characters like these:
Æther, é, Hṛṣṭa
or non-English characters like these:
水鏡.
When debugging in Eclipse, I see them just fine (as-is) but printing on console prints these as ??? - which is OK for me.
Now, how do I handle these? At first I though I could remove every song that has any character other than the ones in English language. I used the regex ^\\w+$ but it didn't work. I also tried \\w+. That didn't work either.
Then I thought further on how do handle these properly. Any one can help me out? I am perfectly fine with letting these tracks out of the equation, ie. I'm fine with having only English character tracks.
Another question: What is the best way to display these character of console and/or Swing GUI?
You must ensure that you use correct encoding when reading your input first.
Second ensure that the font used in Eclipse on platform you developing has ability to display all these characters. Swing must display unicode chars if you read them correctly.
You will likely want to use UTF-8 everywhere.
I'm trying to write a function to dynamically create midi files on Android. Since there is no javax.sound.midi library I'm just writing the bytes out to file myself. I've found some great guides (see below) so I've been able to create multiple track midis. However I haven't been able to figure out how to switch instruments for any of the tracks so everythign is just using the default instrument.
I think from the documents I read the code I need is to "program change" followed by the program number.
What I've tried so far is writing the following out to a byteoutputstream array:
track.write((byte) 192); // 128 + 64
track.write((byte) x); // x is the instrument number between 1-128.
I've put this before the start of the note on/ note off track information, but it doesn't seem to do anything except make the midi take a long time to start. Am I on the right track here, or am I missing something? Any help is appreciated.
http://faydoc.tripod.com/formats/mid.htm
https://ccrma.stanford.edu/~craig/articles/linuxmidi/misc/essenmidi.html
Finally figured it out. It was a just a simple thing, but I forgot to include track time before the program change. Once I added the 0 byte it worked.
This question already has answers here:
Does Eclipse have line-wrap
(12 answers)
Closed 7 years ago.
I already have word wrap for Eclipse PHP (How can I get word wrap to work in Eclipse PDT for PHP files?). What about Eclipse Java? Is there a similar tool to wrap Java code lines?
Ctrl+Shift+F will format a file in Eclipse, breaking long lines into multiple lines and nicely word-wrapping comments. You can also highlight just a section of text and format that.
I realize this is not an automatic soft/hard word wrap, but I don't think the question was asking for anything fancy.
Just like to point out that word wrapping is a terrible idea in code. I suppose everyone has their own style, but typically you should refactor or rethink blocks of code that take much more than a single average horizontal screen. (about 1280 pixels)
Of course there are always exceptions... like verbose exceptions for example, but these are not critical for code understanding.
Scanning a line that goes beyond a single horizontal screen, or having to read a thought that stacks on multiple lines will make your code much more difficult to figure out.
Additionally, line counts will be weird, as word wrapping will make a single line seem like it takes up 2, 3, or shudder the thought... 4 lines of code.
As far as comments go, line returns should not be much of a problem for anyone.
Also keep in mind, word wrapping code is not a common practice, and you are essentially saying that everyone reading your code should turn word wrapping on, which is, I'm sorry to say, an unnecessarily painful thing to make others working with your code do....
If nesting is causing you the need for word wrap... well this is also a very bad code smell.
That's my two-cents.
This is for anyone who is having the following problem with the "Ahtik" word-wrap plugin in Texlipse: the plugin installs fine, but selecting the "word-wrap" option using the context menu (or pressing ctrl+alt+w) causes the text to wrap momentarily, and then just flick back to being unwrapped (this probably includes anyone using Windows 7).
Here is a fix...straight from the developer himself! I emailed Ahti Kitsik in a last-ditch attempt to find a way round, and was amazed when he actually found a solution, and sent it to me the next day. He suggested that in return I could just make this information widely available.
So, the way to fix it as follows:
Look up the texlipse plugin location. This will probably be in the Eclipse folder, and the address will probably end: ...\eclipse\plugins\net.sourceforge.texlipse_1.5.0.
Backup the plugin.xml file there just in case, and then edit the original by deleting the following chunks of code:
-Firstly, the "action" (starting at line 843):
action
class="net.sourceforge.texlipse.actions.TexWordWrapAction"
definitionId="net.sourceforge.texlipse.commands.texWordWrap"
icon="icons/wrap.gif"
id="net.sourceforge.texlipse.actions.texWordWrap"
label="W&rap text"
menubarPath="net.sourceforge.texlipse.menus.latex/latexGroup"
style="toggle"
toolbarPath="latexGroup"
tooltip="Use word wrap"
-Secondly, the "command" (starting at line 972):
command
categoryId="net.sourceforge.texlipse.latexEditingCategory"
name="Wrap text"
id="net.sourceforge.texlipse.commands.texWordWrap"
(When you have done this, the file should be 1257 lines long, instead of 1271).
Finally, Ahti says: "Start eclipse with -clean command line argument to force reloading of plugin.xml." (Personally I had no idea how to do this, so I just removed and reinstalled his plugin, then exited Eclipse, and edited the code before I restarted it).
The function should work fine now. Hope this helps someone. And thanks again Ahti!
In the meantime, there has been an fork to Ahtik's word wrap plugin which, I must say, works very nice and fixes jumbled line numbering bug: Eclipse Word-Wrap Plug-In
Open Eclipse -> Help -> Install New Software -> Click "Add.." button and copy this line "http://dev.cdhq.de/eclipse/updatesite/luna/" into field Name and Location -> Click OK
Check -> Line Number Ruler and Word Wrap Feature -> Next -> Next -> Finish -> Restard Eclipse!
There are some restricted characters (and even full filenames, in Windows), for file and directory names. This other question covers them already.
Is there a way, in Java, to retrieve this list of forbidden characters, which would be depending on the system (a bit like retrieving the line breaker chars)? Or can I only put the list myself, checking for the system?
Edit: More background on my particular situation, aside from the general question.
I use a default name, coming from some data (no real control over their content), and this name is given to a JFileChooser, as a default file name to use (with setSelectedFile()). However, this one truncates anything prior to the last invalid character.
These default names occasionally end with dates in a "mm/dd/yy" format, which leaves only the "yy", in the default name, because "/" are forbidden. As such, checking for Exceptions is not really an option there, because the file itself is not even created yet.
Edit bis: Hmm, that makes me think, if JFileChooser is truncating the name, it probably has access to a list of such characters, can be interesting to check that further.
Edit ter: Ok, checking sources from JFileChooser shows something completely simple. For the text field, it uses file.getName(). It doesn't actually check for invalid characters, it's simply that it takes the "/" as a path separator, and keeps only the end, the "actual filename". Other forbidden characters actually go through.
When it comes to dealing with "forbidden" characters I'd rather be overcautious and ban/replace all "special" characters that may cause a problem on any filesystem.
Even if technically allowed, sometimes those characters can cause weirdness.
For example, we had an issue where the PDF files were being written (successfully) to a SAN, but when served up via a web server from that location some of the characters would cause issues when we were embedding the PDF in an HTML page that was being rendered in Firefox. It was fine if the PDF was accessed directly and it was fine in other browser. Some weird error with how Firefox and Adobe Reader interact.
Summary: "Special" characters in file names -> weird errors waiting to happen
Ultimately, the only way to be sure is to use a white-list.
Having certain "forbidden characters" is just one of many things that can go wrong when creating a file (others are access rights and file and path name lengths).
It doesn't really make sense to try and catch some of these early when there are others you can't catch until you actually try to create the file. Just handle the exceptions properly.
Have you tried using File.getCanonicalPath and comparing it to the original file name (or whatever is retrieved from getAbsolutePath)?
This will not give you the actual characters, but it may help you in determining whether this is a valid filename in the OS you're running on.
Have a look at this link for some info on how to get the OS the application is running on. Basically you need to use System.getProperty("os.name") and do an equals() or contains() to find out the operating system.
Something to be weary of though is that knowing the OS does not necessarily tell you the underlying file system being used, for example a Mac can read and write onto the FAT32 file system.
source: http://www.mkyong.com/java/how-to-detect-os-in-java-systemgetpropertyosname/